Python extension modules only need to export the PyInit function.
Any other C functions are merely part of the module implementation,
and can therefore be kept private.

In older versions of VTK, these type-generation functions were
be exported so that subclasses in other modules could access them.
But since VTK 8.1, subclasses look up their superclasses via the
Python interpreter, so the exports are superfluous.

It is not necessary to export these functions, since they are only
called from the Init.cxx file within the same module.  Hiding them
results in a tidier DLL interface.

Sean McBride authored 5 months ago and Lucas Givord committed 3 months ago

Check length of offset before taking adrees of a range like `&string[n - 8]`.

Looked for similar cases and also reordered another case to check length first, may or may not have been a problem, but safer this way.

ASan would catch this *during* VTK builds, while generating the wrappings.

(cherry picked from commit ccbda30c)

I am bumping the required JAVA SDK to 11 since it simplifies its usage
which results in improved maintanability. It also eliminates the need to
use bootclasspath.

- Merge VTK_JAVA_TARGET_VERSION and VTK_JAVA_SOURCE_VERSION to
  VTK_JAVA_RELEASE_VERSION.
- RENAME VTK_JAVA_INSTALL to VTK_JAVA_BUILD_MAVEN_PKG.
- Update Java build instructions

Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>

Vicente Bolea authored 4 months ago and Vicente Bolea committed 3 months ago

9821ebf5 java: add versioned libs to jar

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Reviewed-by: Sebastien Jourdain <sebastien.jourdain@kitware.com>
Merge-request: !11769
(cherry picked from commit 16b2b31e)

Introduced in 460eff49 to disambiguate
function calls. Tell clang-tidy to ignore these lines.

This is needed since VTK-m libs in our CI builds are versioned. In
general is unreasonable to except thirparty libs  to support unversioned
builds. For that reason include versioned libs in the generated
native JAR.

Clang (rightly) detects that the `PyCFunction` cast is between invalid
function pointer types. Ignore the warning in-code because we know it is
fine due to the `METH_KEYWORDS` flag for the method.

(cherry picked from commit e83f01c9)

On the Intel oneAPI 2021 compilers, these calls were leading to compilation
errors due to ambiguous calls to __is_path_src:

bits/fs_path.h:119:16: error: call to '__is_path_src' is ambiguous

    : decltype(__is_path_src(std::declval<_Source>(), 0))

Invoking c_str() resolves the ambiguity.

The "reference" extension type for the VTK wrappers has a slot
for x.__round__(digits=0), and if the "digits" parameter was not
set, then an unitialized pointer would be passed instead.  This
change initializes the optional parameter, and also initializes
all non-optional paramters out of an abundance of caution.

Vicente Bolea authored 5 months ago and Vicente Bolea committed 4 months ago

b1b2333a cmake: correct java artifacts in pom.xml

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Reviewed-by: Sebastien Jourdain <sebastien.jourdain@kitware.com>
Merge-request: !11595
(cherry picked from commit 9d49423c)

Jaswant Panchumarti (Kitware) authored 5 months ago and Jaswant Panchumarti (Kitware) committed 4 months ago

- This commit fixes a bug in deserialization of vtkCollection in situation where the item pointers have changed but the total number of items in a collection has not changed since the last time the collection was deserialized.
- Previously, the generated code removed all previous items only when the number of items have changed and added the new items once again. Such a design worked only when the item identifiers remained the same. For example, if the state of a prop collection had a different actor, it would be serialized but never added into the collection.
- Now, the generated code will always remove all previous items and deserialize each individual item from the state before adding it into the collection.

(cherry picked from commit 817d8f41)

This change makes the type checkers aware that these constructors
exist, so that the checkers don't warn about code that calls them.

If the C++ object already existed within VTK, and the Python object
is being created because it is being returned by a method, then we
don't want the creation of the Python object to cause changes to
C++ object attributes that were already set by the C++ VTK code.

For example, if we are getting the output dataset from a C++ VTK
filter, we don't want any C++ attributes of the dataset to change
when the Python part of this pre-existing dataset object is created.

The type check in the override() method was too strict, it was not
allowing the override to be derived from an abstract base class.

- This commit fixes a bug in deserialization of vtkCollection in situation where the item pointers have changed but the total number of items in a collection has not changed since the last time the collection was deserialized.
- Previously, the generated code removed all previous items only when the number of items have changed and added the new items once again. Such a design worked only when the item identifiers remained the same. For example, if the state of a prop collection had a different actor, it would be serialized but never added into the collection.
- Now, the generated code will always remove all previous items and deserialize each individual item from the state before adding it into the collection.

Fixes warning for `re.sub`:

DeprecationWarning: 'count' is passed as positional argument

Recent changes to fix the dependencies of vtkjava_tests for Ninja
have caused problems with dependencies for Unix Makefiles.  This
change makes those previous fixes specific to Ninja, in order to
get the build working properly with Unix Makefiles again.

  -- Changing python class types for current overrides for multiple
  inheritance
  -- Adding proper equality checks for data objects and data arrays
  -- Adding custom `_numpy_attrs` for checking/comparing attributes for
  equality

Check length of offset before taking adrees of a range like `&string[n - 8]`.

Looked for similar cases and also reordered another case to check length first, may or may not have been a problem, but safer this way.

ASan would catch this *during* VTK builds, while generating the wrappings.

A typical threshold is 0.05, but vtkJavaTesting was always
converting it to an int, that is, to zero.

This is done to make sure that the correct
image comparison method is actually utilized.