Made a new vtkm::Tuple class to replace tao tuple.
This version of Tuple should hopefully compile faster. Having our own
implementation should also make it easier to port to new devices.
This cleans up the code a bit by removing duplication. More importantly,
it makes sure that the old ListTag functions work with both the new
`List` and old `ListTagBase`.
Previously we relied on CMake's compiler detection module to build the
macros for using the deprecated attribute. However, CMake created macros
for pre-C++14 versions of the feature, which do not work in all cases.
Also, we have the need to be able to suppress deprecation warnings when
we are implementing a deprecated thing. Since we have to query compilers
ourself, we might as well figure out if the deprecated attribute we want
is supported.
Worst case is that we won't support deprecation warnings everywhere we
could. That will not create incorrect code and we can always add that
later.
The `VTKM_DEPRECATED` macro allows us to remove (and usually replace)
features from VTK-m in minor releases while still following the conventions
of semantic versioning. The idea is that when we want to remove or replace
a feature, we first mark the old feature as deprecated. The old feature
will continue to work, but compilers that support it will start to issue a
warning that the use is deprecated and should stop being used. The
deprecated features should remain viable until at least the next major
version. At the next major version, deprecated features from the previous
version may be removed.
Previously, templates were used in the implementation of CastAndCall to
find the type and call the underlying function. The templates checked
one type at a time.
However, compilers were not always great at optimizing a 15-call deep
stack with an if statement at each one. Instead, use a case statement in
a single function block. This requires providing separate code for each
number of types. Currently, up to 20 are created (with pyexpander). If
there are more than that, then the template recurses.
vtkm::internal::Variant is a simplified version of C++17's std::variant
or boost's variant. It is a template that takes a list of types. The
Variant may be set to any one of those types. A CastAndCall allows you
to call a functor with the appropriately cast type.
how did any of this work?
match other CellSet file layouts.
???
compile in CUDA.
unit tests.
also only serial.
make error message accurate
Well, this compiles and works now.
Did it ever?
use CellShapeTagGeneric
UnitTest matches previous changes.
whoops
Fix linking problems.
Need the same interface
as other ThreadIndices.
add filter test
okay, let's try duplicating CellSetStructure.
okay
inching...
change to wedge in CellSetListTag
Means changing these to support it.
switch back to wedge from generic
compiles and runs
remove ExtrudedType
need vtkm_worklet
vtkm_worklet needs to be included
fix segment count for wedge specialization
need to actually save the index
for the other constructor.
specialize on Explicit
clean up warning
angled brackets not quotes.
formatting
assert(false && ""); emitted a
"warning : controlling expression is constant"
Replace the assertion with an exception, which is more appropriate here
anyway.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
We previously included windows.h in numerous locations using different
techniques to guard against bringing in parts of the file that are bad
(min/max macros, etc). This solves the problem by consistently using
vtkm/internal/Windows.h to setup everything.
This is a fancy array handle that can group entries in another array by
arbitrary amounts. This allows us to implement input and output arrays
with a different sized Vec for each instance. This is necessary for
generating new topologies with cells of different types.
This is a little tricky since they don't seem to have considered that
you will have files in both the source and build directory or that the
file locations will not match exactly with the install locations.
The test is a simple CMake script that finds all files in the build
directory with certain extensions (.h, .cxx, etc.) and makes sure that
the filename is listed somewhere in the CMakeLists.txt file of the same
directory. If the filename is listed in the CMakeLists.txt file, then
there is a good chance it is being addressed by the build.
This should help catch when header files are not being installed. It also
should help verify that test builds are being done on all files. It will
also highlight dead source files.
Move ArrayPortalUniformPointCoordinates to the vtkm::internal namespace
since it is going to be actively used in both control and execution
environments.
Replace usage of extent with simple dimensions. We have decided that
there is not a lot of value in supporting extent in VTK-m.
Also moved from vtkm namespace to vtkm::internal namespace. This change
is to then move the structured connectivity classes to the cont and exec
namespaces.
The functors in the ForEach, StaticTransform, and DynamicTransform
methods sometimes can use the index of the parameter that they are
operating on. This can be a helpful diagnostic in compile and run-time
errors. It is also helpful when linking parameters from one
FunctionInterface with those of another.
This new features are now replacing implementations using the Zip
functionality that was removed earlier. The implementation is actually
simplified a bit.
The Fetch class is responsible for moving data in and out of some
collection in the execution environment. The Fetch class is templated
with a pair of tags (the type of fetch and the aspect) that control the
mechanism used for the fetch.
Previously we just hand coded base lists up to 4 entries, which was fine
for what we were using it for. However, now that we want to support base
types of different sizes, we are going to need much longer lists.
Although we cannot expect every developer to have pyexpander, for those
that do the build will automatically run it and check the expanded file
in the source code. If they match, a descriptive error is given.
We don't automatically update the file because subtle problems might
occur. It is better to alert a developer to fix the problem properly.
This commit removes the usage of the boost preprocessor library to
iteratively generate templates with a variable number of parameters. It
is replaced with a template that is expanded by running it through the
pyexpander macro processing tool (http://pyexpander.sourceforge.net).
One reason for this change is to make the code easier to read. In
particular, it is difficult to understand compiler errors when they
occur deep within an iterating macro. Another reason for this change is
that the Intel compiler currently has a bug that breaks with the boost
preprocessor library.
One issue with this approach is that the macro expansion is not part of
the build process. Although open, pyexpander is not a tool most
developers will have readily installed on their system. Thus, if you
want to make changes to any of the macro code, you have to make sure
pyexpander is installed, then make changes to the input files, then
manually run pyexpander from the command line.
The FunctionInterface class is a convienient way to wrap up a variable
number of arguments and pass them around templated interfaces without
requiring variadic template arguments. It also correctly hands return
arguments.
