Reenable the `vtkm::filter::CellMetric` class and
`vtkm::filter::MetricNames` static variable for backward compatibility.
(Both are of course marked deprecated.)
Also, adjust names in the new `vtkm::filter::mesh_info::CellMetric` to
conform with the rest of VTK-m style for scoped enums.
This header file contained two filters: `CylindricalCoordinateTransform`
and `SphericalCoordinateTransform`. By convention, each header (and
source) file should contain one filter. Now that filters are split into
separate libraries, there is little reason to combine things into header
files.
VTK-m has a deprecation method that supports API changes in minor
releases. When an API change is made, the old API is marked with the
VTKM_DEPRECATED macro. If code attempts to use the old API, it still
works, but the compiler issues a warning that the thing is deprecated
and where to find the new API.
We have recently run into an issue when the API changes have a header
file renamed or moved. We still keep the old header file with the old
API, so code including that file will still work. However, sometimes
code expected the contents of that header file without directly
including that header file. In these cases, the code could get an error
about missing classes.
As an example, consider the change from `DynamicCellSet` to
`UnknownCellSet`/`UncertainCellSet`. The deprecated `DynamicCellSet` is
still around. But there is a lot of code that did not directly include
DynamicCellSet.h. This header file was necessarily included by
DataSet.h. Now, when this code uses `vtkm::cont::DynamicCellSet`, you
get a confusing error that the class does not exist. Backward
compatibility broken.
In response to this, we should be more careful about where we put the
deprecated API. Instead of containing the deprecated API, moved headers
should be empty except for a warning and an inclusion of the new header
file. The deprecated API should be moved to the new header file. For
example, in the case of `DynamicCellSet`, the implementation for the
deprecated `DynamicCellSet` is moved to UnknownCellSet.h, which is
included by anything that was including DynamicCellSet.h before.
If you have a really long list, compilers might error out if you have a
recursive operation on it. Such an error can be confusing, so for now
create an error if the list is too long.
The previous implementation of `ListAt` would iteratively pass through
the list to find the i'th entry. It was made faster by searching through
8 indices at a time, but it could still be time consuming for long
lists.
This change instead uses a divide-and-conquer approach. It does this by
first creating a `vtkm::List` with i repetitions of `const void*`. It
can do this by recursively splitting i in half and appending the
resulting lists together.
It then uses this list of `const void*` by constructing a method that
first takes these i `const void*` arguments, then a pointer, then
whatever. The method returns the type of that pointer. The method is
never actually defined, but a `declspec` can determine what the return
type should be.
This method was taken from brigand
(https://github.com/edouarda/brigand).
The interface for `PointElevation` changed the `SetLowPoint` and
`SetHighPoint` methods to accept a `vtkm::Vec3f_64` instead of 3
`vtkm::Float64`. This means all code using `PointElevation` wrong.
Why not have both?
72c2e4c84 Merge branch 'mesh_info' of gitlab.kitware.com:ollielo/vtk-m into mesh_info
260d25612 make deprecated header more compatable to old one
04e494dd4 tidy-up language usage
236d4c8a2 add newline at eof
ee0f112f0 migrate mesh info filters
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <morelandkd@ornl.gov>
Merge-request: !2703
To serialize an `UnknownArrayHandle`, a pair of lists were created to
specify all possible value and storage types. These were then used in an
`UncertainArrayHandle::CastAndCall`, which would in turn take the cross
of these two lists. This resulted in a _really_ long list that gave
compilers trouble.
Reduce the size of the list by separating out value types by the number
of components, which can be easily deduced.
