The breathe parser was having trouble with using `{}` inside of a
declspec for the return value. Replace this with parenthesis, which
cannot be confused with the openning of the function.
The naming convention for CI jobs is generally `stage:name` where the
`stage` matches the GitLab stage and the `name` is a description.
However, the documentation jobs broke this convention by being called
`docs:type` where `type` is `continuous`, `latest`, or `master`. This
breaks the convention because `docs` is not a stage and `type` does not
really describe the build. This fouls up things like
`reproduce_ci_env.py` that expect the first part of the name to be the
same as the stage.
This changes the names to `build:docs-continuous`, `build:docs-latest`,
and `build:docs-master`. This follows the convention of matching the
names with the stage.
Previously, if you called `Fill` on an `ArrayHandleStride`, you would get
an exception that said the feature was not supported. It turns out that
filling values is very useful in situations where, for example, you need to
initialize an array when processing an unknown type (and thus dealing with
extracted components).
This implementation of `Fill` first attempts to call `Fill` on the
contained array. This only works if the stride is set to 1. If this does
not work, then the code leverages the precompiled `ArrayCopy`. It does this
by first creating a new `ArrayHandleStride` containing the fill value and a
modulo of 1 so that value is constantly repeated. It then reconstructs an
`ArrayHandleStride` for itself with a modified size and offset to match the
start and end indices.
Referencing the `ArrayCopy` was tricky because it kept creating circular
dependencies among `ArrayHandleStride`, `ArrayExtractComponent`, and
`UnknownArrayHandle`. These dependencies were broken by having
`ArrayHandleStride` directly use the internal `ArrayCopyUnknown` function
and to use a forward declaration of `UnknownArrayHandle` rather than
including its header.
The `vtkm::worklet::Keys` object held a `SortedValuesMap` array, an
`Offsets` array, a `Counts` array, and (optionally) a `UniqueKeys` array.
Of these, the `Counts` array is redundant because the counts are trivially
computed by subtracting adjacent entries in the offsets array. This pattern
shows up a lot in VTK-m, and most places we have moved to removing the
counts and just using the offsets.
This change removes the `Count` array from the `Keys` object. Where the
count is needed internally, adjacent offsets are subtracted. The deprecated
`GetCounts` method is implemented by copying values into a new array.
This feature was introduced but is never used anywhere. It is up to the
worklet subclass to determine what to do with the boundaries with the
`BoundaryState` object.
In the future we may have a neighborhood worklet of compile-fixed sized
for better memory access efficiency. If that is the case, we can
reintroduce this idea. We can decide on the right implementation if that
design ever comes to pass.
Most of the CI builds are release, and the timeout set for them makes
sense. But for those debug builds, some of the longer-running tests
often exceed the provided timeout. To rightsize the timeouts, make them
longer for debug builds.
23fbedf54 Order the VTK scalar types to favor used types
053237e90 Favor base types used by VTK-m when making new basic array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3171
23fbedf54 Order the VTK scalar types to favor used types
053237e90 Favor base types used by VTK-m when making new basic array
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Li-Ta Lo <ollie@lanl.gov>
Merge-request: !3171
Reorder the `VTKScalarTypes` to put the repeated types at the bottom.
This will avoid using types like `long` that are essentially the same as
other types (e.g. `long long`) but will still be considered different.
This causes problems when checking against some VTK types (such as
`vtkIdType`).
When calling `NewInstanceBasic` on an `UnknownArrayHandle`, all C base
types will be tried. In some cases, multiple type will match the same
array. When this happens, favor types used by VTK-m (e.g. `long long`
over `long`).
