VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2023-06-01T00:54:49-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18361Release 9.1.02023-06-01T00:54:49-04:00Ben BoeckelRelease 9.1.0# Update VTK
- Update the local copy of `release`.
- If `0` is `0.rc1`, update `master`
- Otherwise, update `release`
```
git fetch origin
git checkout release
git merge --ff-only origin/release # if this fails, there are loca...# Update VTK
- Update the local copy of `release`.
- If `0` is `0.rc1`, update `master`
- Otherwise, update `release`
```
git fetch origin
git checkout release
git merge --ff-only origin/release # if this fails, there are local commits that need to be removed
git submodule update --recursive --init
```
- If `release` is not `master`, ensure merge requests which should be
in the release have been merged. The [`backport-mrs.py`][backport-mrs]
script can be used to find and ensure that merge requests assigned to the
associated milestone are available on the `release` branch.
- Make a commit for each of these changes on a single topic (suggested branch
name: `update-to-v9.1.0`):
- Assemble release notes into `Documentation/release/9.1.md`.
- [x] If `PATCH` is greater than 0, add items to the end of this file.
- [x] If `release` is `master`, update the non-patch version in a
separate commit (so that `master` gets it as well).
- [x] Remove old release note files
- [x] Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
groups
- [x] Update `CMake/vtkVersion.cmake` and tag the commit (tag this commit below)
```
$EDITOR CMake/vtkVersion.cmake
git commit -m 'Update version number to 9.1.0' CMake/vtkVersion.cmake
```
- Create a merge request targeting `release`
- [x] Obtain a GitLab API token for the `kwrobot.release.vtk` user (ask
@ben.boeckel if you do not have one)
- [x] Add the `kwrobot.release.vtk` user to your fork with at least
`Developer` privileges (so it can open MRs)
- [x] Use [the `release-mr`][release-mr] script to open the create the
Merge Request (see script for usage)
- Pull the script for each release; it may have been updated since it
was last used
- The script outputs the information it will be using to create the
merge request. Please verify that it is all correct before creating
the merge request. See usage at the top of the script to provide
information that is either missing or incorrect (e.g., if its data
extraction heuristics fail).
- [x] Get positive review
- [x] `Do: merge`
- [x] Push the tag to the main repository
- [x] `git tag -a -m 'VTK 9.1.0' v9.1.0 commit-that-updated-vtkVersion.cmake`
- [x] `git push origin v9.1.0`
- Gather release assets
- [x] Source (from the `build:source` CI job in the tag pipeline)
- [x] Documentation (from the `release-prep:documentation` CI job in the tag pipeline)
- [x] Wheels (from the `build:wheel-*` jobs).
- Upload assets to `vtk.org`
- [x] `rsync -rptv $tarballs $wheels user@host:vtk_release/9.1/`
- [x] Update `vtk.org/download` with the new release (email
`comm@kitware.com` with filenames and hashes)
- Software process updates (these can all be done independently)
- [x] Update kwrobot with the new `release` branch rules (@ben.boeckel)
- [x] Run [this script][cdash-update-groups] to update the CDash groups
- This must be done after a nightly run to ensure all builds are in the
`release` group
- See the script itself for usage documentation
[backport-mrs]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/backport-mrs.py
[release-mr]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/release-mr.py
[cdash-update-groups]: https://gitlab.kitware.com/utils/cdash-utils/-/blob/master/cdash-update-groups.py
# Post-release
- [x] Post an announcement in the Announcements category on
[discourse.vtk.org](https://discourse.vtk.org/).
/cc @ben.boeckel
/cc @ken-martin
/cc @utkarsh.ayachit9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18351Release 9.1.0.rc42023-06-01T00:54:42-04:00Ben BoeckelRelease 9.1.0.rc4# Update VTK
- Update the local copy of `release`.
- If `0.rc4` is `0.rc1`, update `master`
- Otherwise, update `release`
```
git fetch origin
git checkout release
git merge --ff-only origin/release # if this fails, there are ...# Update VTK
- Update the local copy of `release`.
- If `0.rc4` is `0.rc1`, update `master`
- Otherwise, update `release`
```
git fetch origin
git checkout release
git merge --ff-only origin/release # if this fails, there are local commits that need to be removed
git submodule update --recursive --init
```
- If `release` is not `master`, ensure merge requests which should be
in the release have been merged. The [`backport-mrs.py`][backport-mrs]
script can be used to find and ensure that merge requests assigned to the
associated milestone are available on the `release` branch.
- Make a commit for each of these changes on a single topic (suggested branch
name: `update-to-v9.1.0`):
- Assemble release notes into `Documentation/release/9.1.md`.
- [x] If `PATCH` is greater than 0, add items to the end of this file.
- [x] If `release` is `master`, update the non-patch version in a
separate commit (so that `master` gets it as well).
- [x] Remove old release note files
- [x] Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
groups
- [x] Update `CMake/vtkVersion.cmake` and tag the commit (tag this commit below)
```
$EDITOR CMake/vtkVersion.cmake
git commit -m 'Update version number to 9.1.0.rc4' CMake/vtkVersion.cmake
```
- Create a merge request targeting `release`
- [x] Obtain a GitLab API token for the `kwrobot.release.vtk` user (ask
@ben.boeckel if you do not have one)
- [x] Add the `kwrobot.release.vtk` user to your fork with at least
`Developer` privileges (so it can open MRs)
- [x] Use [the `release-mr`][release-mr] script to open the create the
Merge Request (see script for usage)
- Pull the script for each release; it may have been updated since it
was last used
- The script outputs the information it will be using to create the
merge request. Please verify that it is all correct before creating
the merge request. See usage at the top of the script to provide
information that is either missing or incorrect (e.g., if its data
extraction heuristics fail).
- [x] Get positive review
- [x] `Do: merge`
- [x] Push the tag to the main repository
- [x] `git tag -a -m 'VTK 9.1.0.rc4' v9.1.0.rc4 commit-that-updated-vtkVersion.cmake`
- [x] `git push origin v9.1.0.rc4`
- Gather release assets
- [x] Source (from the `build:source` CI job in the tag pipeline)
- [x] Documentation (from the `release-prep:documentation` CI job in the tag pipeline)
- [x] Wheels (from the `build:wheel-*` jobs).
- Upload assets to `vtk.org`
- [x] `rsync -rptv $tarballs $wheels user@host:vtk_release/9.1/`
- [x] Update `vtk.org/download` with the new release (email
`comm@kitware.com` with filenames and hashes)
- Software process updates (these can all be done independently)
- [x] Update kwrobot with the new `release` branch rules (@ben.boeckel)
- [x] Run [this script][cdash-update-groups] to update the CDash groups
- This must be done after a nightly run to ensure all builds are in the
`release` group
- See the script itself for usage documentation
- Deprecation updates (if `release` is `master`)
- [x] Update deprecation macros for the next release
- [x] Remove deprecated symbols from before the *prior* release
- [x] Update `VTK_MINIMUM_DEPRECATION_LEVEL` to be that of the *prior*
release
[backport-mrs]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/backport-mrs.py
[release-mr]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/release-mr.py
[cdash-update-groups]: https://gitlab.kitware.com/utils/cdash-utils/-/blob/master/cdash-update-groups.py
# Post-release
- [x] Post an announcement in the Announcements category on
[discourse.vtk.org](https://discourse.vtk.org/).
/cc @ben.boeckel
/cc @ken-martin
/cc @utkarsh.ayachit
/cc @vbolea9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18344Destructor of vtkDataEncoder hangs with apparent deadlock2022-07-13T11:57:55-04:00Mark DickinsonDestructor of vtkDataEncoder hangs with apparent deadlockThis issue was cut down from a problem with the Mayavi package. With the Python "vtk" package, I'm able to easily hang the process simply by creating `vtkDataEncoder` instances and then allowing them to be garbage collected.
The followi...This issue was cut down from a problem with the Mayavi package. With the Python "vtk" package, I'm able to easily hang the process simply by creating `vtkDataEncoder` instances and then allowing them to be garbage collected.
The following simple script hangs for me on macOS 10.15.7 on an Intel MacBook Pro, Python 3.9.7, vtk 9.0.3:
```
import vtk
print("Version:", vtk.VTK_VERSION)
print("Starting loop")
for _ in range(100):
vtk.vtkDataEncoder()
print("Finished")
```
The output is just:
```
(mayavi) mdickinson@mirzakhani Desktop % python vtk_bug.py
Version: 9.0.3
Starting loop
```
Attaching lldb to the hanging process shows that it's locked at the point where it's trying to tear down the thread pool:
```
mdickinson@mirzakhani ~ % lldb -p 6292
(lldb) process attach --pid 6292
Process 6292 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00007fff70dad55e libsystem_kernel.dylib`__ulock_wait + 10
libsystem_kernel.dylib`__ulock_wait:
-> 0x7fff70dad55e <+10>: jae 0x7fff70dad568 ; <+20>
0x7fff70dad560 <+12>: movq %rax, %rdi
0x7fff70dad563 <+15>: jmp 0x7fff70dac629 ; cerror_nocancel
0x7fff70dad568 <+20>: retq
Target 0: (Python) stopped.
Executable module set to "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python".
Architecture set to: x86_64h-apple-macosx-.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x00007fff70dad55e libsystem_kernel.dylib`__ulock_wait + 10
frame #1: 0x00007fff70e705c2 libsystem_pthread.dylib`_pthread_join + 347
frame #2: 0x000000010a4f28a2 libvtkCommonCore-9.0.dylib`vtkMultiThreader::TerminateThread(int) + 226
frame #3: 0x000000010a8845cc libvtkWebCore-9.0.dylib`vtkDataEncoder::vtkInternals::TerminateAllWorkers() + 124
frame #4: 0x000000010a88467d libvtkWebCore-9.0.dylib`vtkDataEncoder::~vtkDataEncoder() + 29
frame #5: 0x000000010a283e3d libvtkWrappingPythonCore-9.0.dylib`vtkPythonUtil::RemoveObjectFromMap(_object*) + 157
frame #6: 0x000000010a268215 libvtkWrappingPythonCore-9.0.dylib`PyVTKObject_Delete + 37
frame #7: 0x000000010980fb57 Python`_PyEval_EvalFrameDefault + 2263
frame #8: 0x0000000109818be2 Python`_PyEval_EvalCode + 2008
frame #9: 0x000000010980f1c8 Python`PyEval_EvalCode + 57
frame #10: 0x000000010984a059 Python`run_eval_code_obj + 110
frame #11: 0x0000000109849230 Python`run_mod + 103
frame #12: 0x00000001098493ae Python`pyrun_file + 216
frame #13: 0x0000000109847a4e Python`PyRun_SimpleFileExFlags + 660
frame #14: 0x000000010985f7c7 Python`Py_RunMain + 1839
frame #15: 0x000000010985fb36 Python`pymain_main + 360
frame #16: 0x000000010985fb8b Python`Py_BytesMain + 42
frame #17: 0x00007fff70c6acc9 libdyld.dylib`start + 1
frame #18: 0x00007fff70c6acc9 libdyld.dylib`start + 1
```9.1Utkarsh AyachitUtkarsh Ayachithttps://gitlab.kitware.com/vtk/vtk/-/issues/18343Config failure for python static build2021-10-28T18:10:25-04:00David GobbiConfig failure for python static buildOn ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP...On ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP_PYTHON=ON
```
```text
CMake Error at CMake/vtkModuleWrapPython.cmake:987 (target_link_libraries):
INTERFACE library can only be used with the INTERFACE keyword of
target_link_libraries
```
The cmake code in question:
```cmake
if (_vtk_python_UTILITY_TARGET)
target_link_libraries("${_vtk_python_TARGET_NAME}"
PRIVATE
"${_vtk_python_UTILITY_TARGET}")
endif ()
```
Tested with cmake 3.16.3 and with 3.21, both produced the same error.9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18328Streamline configuration of client project adding PYTHON_* and Python3_* vari...2021-10-21T21:03:12-04:00Jean-Christophe Fillion-RobinStreamline configuration of client project adding PYTHON_* and Python3_* variables vtk-config (or alike)To streamline the configuration of project that do not directly use python but depends on a VTK build tree wrapped in python, it would be helpful to include all the python variables in the VTK configuration associated with the build tree...To streamline the configuration of project that do not directly use python but depends on a VTK build tree wrapped in python, it would be helpful to include all the python variables in the VTK configuration associated with the build tree.
The goal is to avoid passing blocks like these ones and expect VTK to find the python it was build against:
```
-DPYTHON_EXECUTABLE:FILEPATH=${PYTHON_EXECUTABLE}
-DPYTHON_LIBRARY:FILEPATH=${PYTHON_LIBRARY}
-DPYTHON_INCLUDE_DIR:FILEPATH=${PYTHON_INCLUDE_DIR}
-DPython3_EXECUTABLE:FILEPATH=${Python3_EXECUTABLE}
-DPython3_LIBRARY:FILEPATH=${Python3_LIBRARY}
-DPython3_INCLUDE_DIR:PATH=${Python3_INCLUDE_DIR}
```
Notes:
* These comments only apply to a VTK build tree and **NOT** a VTK install tree.
References:
* https://github.com/openigtlink/SlicerOpenIGTLink/pull/116
* https://discourse.slicer.org/t/superbuild-extension-builds-failed-when-python-was-installed-good-solution/199389.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18299vtk-config do not export vtkOpenGLOptions variables2022-07-26T12:18:02-04:00Paul Lafoixvtk-config do not export vtkOpenGLOptions variablesWhen using an external vtk, the variables VTK_CAN_DO_ONSCREEN or VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN are not exportedWhen using an external vtk, the variables VTK_CAN_DO_ONSCREEN or VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN are not exported9.1https://gitlab.kitware.com/vtk/vtk/-/issues/18247Move release process steps into CI2023-10-07T13:03:41-04:00Ben BoeckelMove release process steps into CINumerous steps from the release process can be moved into the CI pipeline. Of note:
- [x] creating source and documentation tarballs (!8128)
- [x] uploading documentation and source tarballs to vtk.org
- [x] uploading documentatio...Numerous steps from the release process can be moved into the CI pipeline. Of note:
- [x] creating source and documentation tarballs (!8128)
- [x] uploading documentation and source tarballs to vtk.org
- [x] uploading documentation to vtk.org (not nightly, but a versioned directory)
- [x] uploading wheels to VTK's package registry (!8128)
- [ ] creating a release on VTK's repository
- [ ] uploading assets to VTK's repository and linking them to the release
For prior art on uploading assets and creating releases, the CI jobs in [the `ci-utilities` repository](https://gitlab.kitware.com/utils/ci-utilities/) can be used.
The release process checklist should be updated to reflect these changes.
Cc: @will.schroeder @utkarsh.ayachit @brad.king9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18224CommonCore dependency on kissfft is unnecessary2021-05-28T03:02:38-04:00David GobbiCommonCore dependency on kissfft is unnecessaryMR !5930 added vtkFFT to the CommonCore module. This made kissfft a dependency of CommonCore. As one of the goals of modularization, we want the core modules to have as few dependencies as possible.
A better module for vtkFFT is Common...MR !5930 added vtkFFT to the CommonCore module. This made kissfft a dependency of CommonCore. As one of the goals of modularization, we want the core modules to have as few dependencies as possible.
A better module for vtkFFT is CommonMath, which currently contains solvers, optimizers, and similar mathematical code. This will move the kissfft dependency from CommonCore to CommonMath.
This change must be done before the VTK 9.1 release, because modifying the dependency chain after a release will result in backwards compatibility problems for users.9.1https://gitlab.kitware.com/vtk/vtk/-/issues/18097DeprecationWarning: Converting `np.character` to a dtype is deprecated. When ...2023-10-23T21:03:13-04:00Alex MoldovanDeprecationWarning: Converting `np.character` to a dtype is deprecated. When using pv.wrap(np.array)Getting a
`\Anaconda3\envs\py37_sd\lib\site-packages\vtkmodules\util\numpy_support.py:68:DeprecationWarning: Converting np.character to a dtype is deprecated. The current result is np.dtype(np.str_) which is not strictly correct. Note t...Getting a
`\Anaconda3\envs\py37_sd\lib\site-packages\vtkmodules\util\numpy_support.py:68:DeprecationWarning: Converting np.character to a dtype is deprecated. The current result is np.dtype(np.str_) which is not strictly correct. Note that np.character is generally deprecated and S1 should be used.`
Warning when I run
```python
import vtk
import numpy as np
import pyvista as pv
a = np.array([[0.5,0.5,0.5]])
b = pv.wrap(a)
```
Updated Numpy, VTK and latest PyVista
```md
# Name Version Build Channel
alabaster 0.7.12 py37_0
appdirs 1.4.4 py_0
argon2-cffi 20.1.0 py37he774522_1
astropy 4.2 py37h2bbff1b_0
async_generator 1.10 py37h28b3542_0
atomicwrites 1.4.0 py_0
attrs 20.3.0 pyhd3eb1b0_0
babel 2.9.0 pyhd3eb1b0_0
backcall 0.2.0 py_0
blas 1.0 mkl
bleach 3.2.3 pyhd3eb1b0_0
brotlipy 0.7.0 py37h2bbff1b_1003
bzip2 1.0.8 he774522_0
ca-certificates 2021.1.19 haa95532_0
cached-property 1.5.2 py_0
certifi 2020.12.5 py37haa95532_0
cffi 1.14.4 py37hcd4344a_0
cftime 1.3.1 py37h080aedc_0
chardet 4.0.0 py37haa95532_1003
colorama 0.4.4 pyhd3eb1b0_0
coverage 5.3.1 py37h2bbff1b_2
cryptography 3.3.1 py37hcd4344a_0
curl 7.71.1 h2a8f88b_1
cycler 0.10.0 py37_0
decorator 4.4.2 py_0
defusedxml 0.6.0 py_0
docutils 0.16 py37_1
docxtpl 0.11.3 pyhd3deb0d_0 conda-forge
double-conversion 3.1.5 ha925a31_1
eigen 3.3.7 h74a9793_0
entrypoints 0.3 py37_0
expat 2.2.10 h33f27b4_2
ffmpeg 4.3.1 ha925a31_0 conda-forge
freetype 2.10.4 hd328e21_0
geos 3.8.0 h33f27b4_0
gl2ps 1.4.2 h0597ee9_0 conda-forge
glew 2.1.0 h39d44d4_2 conda-forge
h5py 3.1.0 nompi_py37h19fda09_100 conda-forge
hdf4 4.2.13 h712560f_2
hdf5 1.10.6 nompi_h5268f04_1114 conda-forge
icc_rt 2019.0.0 h0cc432a_1
icu 58.2 ha925a31_3
idna 2.10 pyhd3eb1b0_0
imageio 2.9.0 py_0
imagesize 1.2.0 py_0
importlib-metadata 2.0.0 py_1
importlib_metadata 2.0.0 1
iniconfig 1.1.1 pyhd3eb1b0_0
intel-openmp 2020.2 254
ipykernel 5.3.4 py37h5ca1d4c_0
ipython 7.10.2 py37h39e3cac_0
ipython_genutils 0.2.0 pyhd3eb1b0_1
ipywidgets 7.6.3 pyhd3eb1b0_1
jedi 0.17.2 py37haa95532_1
jinja2 2.11.2 pyhd3eb1b0_0
joblib 1.0.0 pyhd3eb1b0_0
jpeg 9d h8ffe710_0 conda-forge
jsoncpp 1.8.4 h74a9793_0
jsonschema 3.2.0 py_2
jupyter 1.0.0 py37_7
jupyter_client 6.1.7 py_0
jupyter_console 6.2.0 py_0
jupyter_core 4.7.0 py37haa95532_0
jupyterlab_pygments 0.1.2 py_0
jupyterlab_widgets 1.0.0 pyhd3eb1b0_1
kiwisolver 1.3.0 py37hd77b12b_0
krb5 1.18.2 hc04afaa_0
libcurl 7.71.1 h2a8f88b_1
libiconv 1.15 h1df5818_7
libnetcdf 4.7.4 nompi_h3a9aa94_107 conda-forge
libogg 1.3.2 he774522_0
libpng 1.6.37 h2a8f88b_0
libsodium 1.0.18 h62dcd97_0
libssh2 1.9.0 h7a1dbc1_1
libtheora 1.1.1 h62dcd97_1004 conda-forge
libtiff 4.1.0 h56a325e_1
libxml2 2.9.10 hb89e7f3_3
libxslt 1.1.34 he774522_0
loguru 0.5.3 py37hc8dfbb8_2 conda-forge
lxml 4.6.2 py37h9b66d53_0
lz4-c 1.9.2 hf4a77e7_3
m2w64-gcc-libgfortran 5.3.0 6
m2w64-gcc-libs 5.3.0 7
m2w64-gcc-libs-core 5.3.0 7
m2w64-gmp 6.1.0 2
m2w64-libwinpthread-git 5.0.0.4634.697f757 2
markupsafe 1.1.1 py37hfa6e2cd_1
matplotlib 3.3.2 haa95532_0
matplotlib-base 3.3.2 py37hba9282a_0
meshio 4.3.8 pyhd8ed1ab_0 conda-forge
mistune 0.8.4 py37hfa6e2cd_1001
mkl 2020.2 256
mkl-service 2.3.0 py37h196d8e1_0
mkl_fft 1.2.0 py37h45dec08_0
mkl_random 1.1.1 py37h47e9c7a_0
more-itertools 8.6.0 pyhd3eb1b0_0
msys2-conda-epoch 20160418 1
nb_conda 2.2.1 py37_0
nb_conda_kernels 2.3.1 py37haa95532_0
nbclient 0.5.1 py_0
nbconvert 6.0.7 py37_0
nbformat 5.1.2 pyhd3eb1b0_1
nest-asyncio 1.4.3 pyhd3eb1b0_0
netcdf4 1.5.5.1 nompi_py37h4965ef1_101 conda-forge
nose 1.3.7 pyhd3eb1b0_1006
notebook 6.2.0 py37haa95532_0
numpy 1.19.2 py37hadc3359_0
numpy-base 1.19.2 py37ha3acd2a_0
olefile 0.46 py37_0
openssl 1.1.1i h2bbff1b_0
packaging 20.8 pyhd3eb1b0_0
pandas 1.1.5 py37hf11a4ad_0
pandoc 2.11 h9490d1a_0
pandocfilters 1.4.3 py37haa95532_1
parso 0.7.0 py_0
pickleshare 0.7.5 pyhd3eb1b0_1003
pillow 7.0.0 py37hcc1f983_0
pip 20.3.3 py37haa95532_0
pluggy 0.13.1 py37_0
proj 7.1.1 h7d85306_3 conda-forge
prometheus_client 0.9.0 pyhd3eb1b0_0
prompt-toolkit 3.0.8 py_0
prompt_toolkit 3.0.8 0
pugixml 1.10 ha925a31_1 conda-forge
py 1.10.0 pyhd3eb1b0_0
pycparser 2.20 py_2
pyerfa 1.7.1.1 py37h2bbff1b_1
pygments 2.7.4 pyhd3eb1b0_0
pyopenssl 20.0.1 pyhd3eb1b0_1
pyparsing 2.4.7 pyhd3eb1b0_0
pyqt 5.9.2 py37h6538335_2
pyreadline 2.1 py37_1
pyrsistent 0.17.3 py37he774522_0
pysocks 1.7.1 py37_1
pytest 6.2.2 py37haa95532_1
python 3.7.9 h60c2a47_0
python-dateutil 2.8.1 py_0
python-docx 0.8.10 py_0 conda-forge
python_abi 3.7 1_cp37m conda-forge
pytz 2020.5 pyhd3eb1b0_0
pyvista 0.27.4 pyhd8ed1ab_0 conda-forge
pywin32 227 py37he774522_1
pywinpty 0.5.7 py37_0
pyzmq 20.0.0 py37hd77b12b_1
qt 5.9.7 vc14h73c81de_0
qtconsole 4.7.7 py_0
qtpy 1.9.0 py_0
requests 2.25.1 pyhd3eb1b0_0
scikit-learn 0.23.2 py37h47e9c7a_0
scipy 1.5.2 py37h9439919_0
scooby 0.5.6 pyh9f0ad1d_0 conda-forge
seaborn 0.11.1 pyhd3eb1b0_0
send2trash 1.5.0 pyhd3eb1b0_1
setuptools 52.0.0 py37haa95532_0
shapely 1.7.1 py37h210f175_0
sip 4.19.8 py37h6538335_0
six 1.15.0 py37haa95532_0
snowballstemmer 2.1.0 pyhd3eb1b0_0
sphinx 3.4.3 pyhd3eb1b0_0
sphinxcontrib-applehelp 1.0.2 py_0
sphinxcontrib-devhelp 1.0.2 py_0
sphinxcontrib-htmlhelp 1.0.3 py_0
sphinxcontrib-jsmath 1.0.1 py_0
sphinxcontrib-qthelp 1.0.3 py_0
sphinxcontrib-serializinghtml 1.1.4 py_0
sqlite 3.33.0 h2a8f88b_0
tbb 2020.3 h74a9793_0
tbb-devel 2020.3 h74a9793_0
terminado 0.9.2 py37haa95532_0
testpath 0.4.4 py_0
threadpoolctl 2.1.0 pyh5ca1d4c_0
tk 8.6.10 he774522_0
toml 0.10.1 py_0
tornado 6.1 py37h2bbff1b_0
traitlets 5.0.5 py_0
urllib3 1.26.3 pyhd3eb1b0_0
utfcpp 3.1.2 0 conda-forge
vc 14.2 h21ff451_1
vs2015_runtime 14.27.29016 h5e58377_2
vtk 9.0.1 no_osmesa_py37h047e439_102 conda-forge
wcwidth 0.2.5 py_0
webencodings 0.5.1 py37_1
wheel 0.36.2 pyhd3eb1b0_0
widgetsnbextension 3.5.1 py37_0
win32_setctime 1.0.3 py_0 conda-forge
win_inet_pton 1.1.0 py37haa95532_0
wincertstore 0.2 py37_0
winpty 0.4.3 4
xz 5.2.5 h62dcd97_0
zeromq 4.3.3 ha925a31_3
zipp 3.4.0 pyhd3eb1b0_0
zlib 1.2.11 h62dcd97_4
zstd 1.4.5 h04227a9_0
```9.1David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/18039Image rendering with multisamples fails in VTK master2021-05-17T15:01:26-04:00David GobbiImage rendering with multisamples fails in VTK masterAfter !6989 (as found with git bisect), image rendering fails on my linux system (with amdgpu drivers) unless I turn multisamples off. For example, here are two screenshots for TestCheckerboardWidget. Note that the test doesn't actually ...After !6989 (as found with git bisect), image rendering fails on my linux system (with amdgpu drivers) unless I turn multisamples off. For example, here are two screenshots for TestCheckerboardWidget. Note that the test doesn't actually fail, since the saved regression image is correct, even though the image displayed on the screen is incorrect (very weird!).
![bad](/uploads/ce324fe7de4de7ff6c834f82450e5b30/bad.png)
![good](/uploads/8627d70e63a5bfc5d42f34d132035ff8/good.png)
The problem seems to be the MSAA code in `vtkOpenGLRenderWindow.cxx`. I can make the problem go away by commenting out the `copiedColor` line in the `Frame()` method:
```c++
if (this->ResolveQuad->Program && this->ResolveQuad->Program->GetCompiled())
{
this->GetState()->vtkglDisable(GL_DEPTH_TEST);
this->GetState()->vtkglDisable(GL_BLEND);
auto tex = this->RenderFramebuffer->GetColorAttachmentAsTextureObject(0);
tex->Activate();
this->ResolveQuad->Program->SetUniformi("samplecount", this->MultiSamples);
this->ResolveQuad->Program->SetUniformi("tex", tex->GetTextureUnit());
this->ResolveQuad->Render();
tex->Deactivate();
//copiedColor = true;
this->GetState()->vtkglEnable(GL_DEPTH_TEST);
this->GetState()->vtkglEnable(GL_BLEND);
}
```
Oddly enough, this `copiedColor` line does not appear in the otherwise identical code block in the `StereoMidpoint()` method!9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17959vtkContextView segfault in python on Windows 102021-02-24T13:54:56-05:00T.J. CoronavtkContextView segfault in python on Windows 10As per [this topic](https://discourse.vtk.org/t/vtk-9-python-vtkcontextview-not-working/3761/4), here's a script to reproduce the crash:
```
import vtk
chart = vtk.vtkChartXY()
f = vtk.vtkPiecewiseFunction()
f.AddPoint(0, 0.0)
f.AddPoin...As per [this topic](https://discourse.vtk.org/t/vtk-9-python-vtkcontextview-not-working/3761/4), here's a script to reproduce the crash:
```
import vtk
chart = vtk.vtkChartXY()
f = vtk.vtkPiecewiseFunction()
f.AddPoint(0, 0.0)
f.AddPoint(500, 1)
pf = vtk.vtkPiecewiseFunctionItem()
pf.SetPiecewiseFunction(f)
chart.AddPlot(pf)
view = vtk.vtkContextView()
view.GetScene().AddItem(chart)
view.GetInteractor().Start()
```
I have confirmed the issue on Windows 10, Python 3.8. On OS X 10.15, this is issue does not occur.9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17904`vtkHyperTreeGrid` ghost types2020-05-22T09:49:40-04:00Yohann Bearzi (Kitware)`vtkHyperTreeGrid` ghost typesCurrently, `vtkHyperTreeGridGhostCellsGenerator` generates binary ghosts: cells (or more precisely vertices) are ghosts, or they are not. However, righting algorithms implicating ghosts might need some extra topological information on su...Currently, `vtkHyperTreeGridGhostCellsGenerator` generates binary ghosts: cells (or more precisely vertices) are ghosts, or they are not. However, righting algorithms implicating ghosts might need some extra topological information on such vertices to avoid unnecessary search / communication.
This issue aims to define what types of ghosts are relevant for an htg. I will propose a set of ghost types, which we can then amend. Note that in the current ghost implementation, an entire hypertree is held by one and only one process, but in the future, it could make sense to split a hypertree among multiple processes.
Before I list a proposal for those types, I think we should call them `TreeVertexGhostType` and not `VertexGhostType`, since if at some point someone wants to do ghosts on graphs that are not trees, it would be more legitimate to keep the pure vertex naming for this case.
Here is what could be defined in `vtkDataSetAttributes.h`:
```
enum TreeVertexGhostType
{
DUPLICATETREEVERTEX = 1, // the vertex is present on multiple processors.
PUREGHOSTTREEVERTEX = 2, // the vertex sub-tree is only composed of ghost vertices.
PUREGHOSTROOTTREEVERTEX = 4, // the vertex is the first pure ghost vertex in the current path to the root of the hypertree.
INCOMPLETETREEVERTEX = 8, // the vertex is refined into a subtree in another process, but is locally a leaf.
HIDDENTREEVERTEX = 16 // the vertex is needed for hypertree topology, but does not hold any data information.
};
```
Adding a `REFINEDTREEVERTEX` would not be relevant in most cases since this information can be accessed through cursors using `IsLeaf()` method. But maybe we want to be able to know about it by only looking at the ghost array without actually traversing the htg. This is to be discussed.
Solving this issue implies changing `vtkHyperTreeGridGhostCellsGenerator` to acknowledge these types.9.1Yohann Bearzi (Kitware)Yohann Bearzi (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/17896Follow-up from "FindLibHaru, FindFreeType: handle multi-config library variab...2020-05-13T16:33:44-04:00Ben BoeckelFollow-up from "FindLibHaru, FindFreeType: handle multi-config library variables"The following discussion from !6890 should be addressed:
- [ ] @Neumann-A started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6890#note_756249): (+9 comments)
> @ben.boeckel: I think you need to change `vtk_...The following discussion from !6890 should be addressed:
- [ ] @Neumann-A started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6890#note_756249): (+9 comments)
> @ben.boeckel: I think you need to change `vtk_detect_library_type` because it is fair game to pass any of those variables via the cmake command line and skip the find_library call in any FindModule.cmake9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17894Add date to the vtk version2020-05-28T08:50:22-04:00Mathieu Westphal (Kitware)Add date to the vtk versionIt is currently unsupported to check that the VTK version in use by another application is of a specific date.
It would be nice to be able to do the following check :
`#if VTK_BUILD_VERSION < VTK_VERSION(9, 0, 20200511)`It is currently unsupported to check that the VTK version in use by another application is of a specific date.
It would be nice to be able to do the following check :
`#if VTK_BUILD_VERSION < VTK_VERSION(9, 0, 20200511)`9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17838visRTX pathtracer does not respect the renderer's background color2021-04-13T12:19:11-04:00Jean M. FavrevisRTX pathtracer does not respect the renderer's background colorSwitching renderer type to either "pathtracer" or "optix pathtracer" results in a black background, where the "scivis" renderer correctly uses the background color set.
I have tried setting a different background color in TestOSPRayDept...Switching renderer type to either "pathtracer" or "optix pathtracer" results in a black background, where the "scivis" renderer correctly uses the background color set.
I have tried setting a different background color in TestOSPRayDepthOfField.cxx, but it is always black.9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17711Disabled examples in VTK 8.902021-03-23T19:19:11-04:00David GobbiDisabled examples in VTK 8.90Several examples were disabled when VTK adopted the new build system.
Is there any plan to fix and re-enable these examples for VTK 9?
Here is a snipped from Examples/CMakeLists.txt that shows what is disabled:
```
if (ANDROID)
#add_e...Several examples were disabled when VTK adopted the new build system.
Is there any plan to fix and re-enable these examples for VTK 9?
Here is a snipped from Examples/CMakeLists.txt that shows what is disabled:
```
if (ANDROID)
#add_example(Android)
elseif (APPLE_IOS)
#add_example(iOS)
else ()
add_example(AMR/Cxx)
add_example(Annotation/Cxx/LabeledMesh)
#add_example(Array/Cxx)
#add_example(Build/vtkLocal)
#add_example(Build/vtkMy)
add_example(Charts/Cxx)
add_example(DataManipulation/Cxx)
add_example(GUI/Qt/FourPaneViewer)
add_example(GUI/Qt/GraphicsView)
add_example(GUI/Qt/ImageViewer)
add_example(GUI/Qt/SimpleView)
add_example(GUI/Qt/TouchGestureViewer)
add_example(IO/Cxx)
add_example(ImageProcessing/Cxx)
add_example(Infovis/Cxx)
# TODO: These 2 do testing and need more work.
#add_example(Medical/Cxx)
#add_example(Modelling/Cxx)
add_example(MultiBlock/Cxx)
add_example(ParallelProcessing/Generic/Cxx)
#add_example(Rendering/Cxx)
#add_example(Tutorial/Step1/Cxx)
#add_example(Tutorial/Step2/Cxx)
#add_example(Tutorial/Step3/Cxx)
#add_example(Tutorial/Step4/Cxx)
#add_example(Tutorial/Step5/Cxx)
#add_example(Tutorial/Step6/Cxx)
#add_example(VisualizationAlgorithms/Cxx)
#add_example(VolumeRendering/Cxx)
#add_example(Widgets/Cxx)
if (WIN32)
#add_example(GUI/Win32/SimpleCxx)
#add_example(GUI/Win32/SampleMFC)
#add_example(GUI/Win32/vtkMFC)
endif ()
endif ()
```
Medical and Modelling examples are addressed in !61449.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17698mirror and/or move vtk.org downloads to some place offsite2020-08-24T09:51:13-04:00David E. DeMarlemirror and/or move vtk.org downloads to some place offsitecmake has had good success moving downloads from Kitware over to github, and users have better download times. We should do the same with vtk.cmake has had good success moving downloads from Kitware over to github, and users have better download times. We should do the same with vtk.9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17682Incorrect casting of double into unsigned long introduced by 2018 change of v...2020-02-10T08:38:32-05:00Philippe P. PébaÿIncorrect casting of double into unsigned long introduced by 2018 change of vtkOrderStatisticsCommit 56bf715c939 modified line 228 of `Filters/Statistics/vtkOrderStatistics.cxx` as follows:
`++ histogram[static_cast<unsigned long>(quantum)];`
This casting of `quantum` from a double into an unsigned long causes the histogram su...Commit 56bf715c939 modified line 228 of `Filters/Statistics/vtkOrderStatistics.cxx` as follows:
`++ histogram[static_cast<unsigned long>(quantum)];`
This casting of `quantum` from a double into an unsigned long causes the histogram support to collapse into a singleton, when the `Quantize` mode is turned **ON**.
Instead, this line should be fixed to its original implementation, as follows:
`++ histogram[quantum];`
I confirm that returning this line to its previous state fixes the problem.
**NB:** It is not necessary to revert the entire commit9.1David ThompsonDavid Thompsonhttps://gitlab.kitware.com/vtk/vtk/-/issues/17515Fails to find PTHREAD_MUTEX_RECURSIVE on FreeBSD2020-05-16T19:06:58-04:00yurivictFails to find PTHREAD_MUTEX_RECURSIVE on FreeBSDThis line fails:
```
CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)
```
Log:
```
Determining if the PTHREAD_MUTEX_RECURSIVE exist failed with the following output:
Change Dir: /tmp/x/CMakeFiles/...This line fails:
```
CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)
```
Log:
```
Determining if the PTHREAD_MUTEX_RECURSIVE exist failed with the following output:
Change Dir: /tmp/x/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/gmake" "cmTC_d1e0e/fast"
/usr/local/bin/gmake -f CMakeFiles/cmTC_d1e0e.dir/build.make CMakeFiles/cmTC_d1e0e.dir/build
gmake[1]: Entering directory '/tmp/x/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_d1e0e.dir/CheckSymbolExists.c.o
/usr/bin/cc -o CMakeFiles/cmTC_d1e0e.dir/CheckSymbolExists.c.o -c /tmp/x/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/tmp/x/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:18: error: cannot take the address of an rvalue of type 'int'
return ((int*)(&PTHREAD_MUTEX_RECURSIVE))[argc];
^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```9.1Sean McBrideSean McBridehttps://gitlab.kitware.com/vtk/vtk/-/issues/18582HDF Files no longer reading in VTK 9.22022-06-28T03:12:19-04:00Alex KaszynskiHDF Files no longer reading in VTK 9.2`vtk==9.2.0rc1` on Python 3.10 appears to have a regression when reading the HDF files contained in this directory:
https://github.com/pyvista/vtk-data/tree/master/Data/hdf
Error:
```
2022-06-26 03:47:57.852 ( 122.743s) [ D2BFC0...`vtk==9.2.0rc1` on Python 3.10 appears to have a regression when reading the HDF files contained in this directory:
https://github.com/pyvista/vtk-data/tree/master/Data/hdf
Error:
```
2022-06-26 03:47:57.852 ( 122.743s) [ D2BFC000]vtkHDFReaderImplementat:298 ERR| vtkHDFReader (0x559502ac8290): Can't find the `Type` attribute.
2022-06-26 03:47:57.852 ( 122.744s) [ D2BFC000] vtkExecutive.cxx:740 ERR| vtkCompositeDataPipeline (0x559502c40f40): Algorithm vtkHDFReader (0x559502ac8290) returned failure for request: vtkInformation (0x559502e7f4d0)
Debug: Off
Modified Time: 96
Reference Count: 1
Registered Events: (none)
Request: REQUEST_DATA_OBJECT
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
```
Reproduce with:
```py
from pyvista import examples
examples.download_can(partial=False)
```9.2