GitLab

* Use angleDelta() if delta() does not exist (PyQt5)
* Only zoom if cumulative delta is greater/less than +/- 15 degrees

use _PyUnicode_AsString for Python 3.0-3.2

Boris Nagaev authored Dec 20, 2015 and David Gobbi committed Jan 08, 2016

If ${VTK_SOURCE_DIR} contains "++", the following error
is produced by CMake:

> RegularExpression::compile(): Nested *?+.
> RegularExpression::compile(): Error in compile.

Use STREQUAL instead of MATCHES to compare strings.

VTK no longer supports any compilers that do not provide this type.
Therefore all code conditional on VTK_TYPE_USE_LONG_LONG can be made
unconditional.  Leave the macro defined to tell dependent projects that
APIs using the type are available in case they still support versions of
VTK that make it conditional.

VTK no longer supports any compilers that have `__int64` but not a
`long` or `long long` that is 64-bit.  Therefore all code that is
conditional on VTK_TYPE_USE___INT64 is never used and can be dropped.

https://stackoverflow.com/questions/2238818/java-unchecked-call-to-getconstructorjava-lang-class

Detected by otherPrint tcl test

The string and char literals had a mistake that caused a mis-parse if
a backslash appeared before the terminating quote.  The new patterns
fix the bug, and also allow for multi-line string literals.

1.5 is deprecated and won't be around much longer.

Ben Boeckel authored Nov 19, 2015 and David Gobbi committed Nov 19, 2015

Seems GCC is happy without this?

Ben Boeckel authored Nov 18, 2015 and David Gobbi committed Nov 19, 2015

It isn't needed after this point anymore.

Ben Boeckel authored Nov 18, 2015 and David Gobbi committed Nov 19, 2015

In Python3, we take the actual object and construct a new bytes() object
from it. We then take a pointer to its data and decref the bytes object.
If the garbage collector runs between the decref and the use of the
classname variable further down, it is a use-after-free.

Seems GCC is happy without this?

It isn't needed after this point anymore.

In Python3, we take the actual object and construct a new bytes() object
from it. We then take a pointer to its data and decref the bytes object.
If the garbage collector runs between the decref and the use of the
classname variable further down, it is a use-after-free.

1. Defining a gilEnsurer class to use as RAII for gil
2. Ensuring critical calls to python, where they could be concurrency, only when a cmake option is defined
3. Correcting the access to python in vtkPythonInterpreter::Initialize
4. Forcing the use of gil in the Interactive Python Interepreter for auto completion http://www.vtk.org/Bug/view.php?id=15699
5. Forcing the use of gil for prependPythonPath : http://www.vtk.org/Bug/view.php?id=15698

The file should be excluded instead.

Despite the comment, I see no reason why
‘its presence is necessary’.  The string
‘yy_trans_info’ appears nowhere else in the codebase.

Use == instead of <=

VTK no longer supports any compiler (VS 6) with this behavior.
Drop our compatibility layer for this case.

Thanks David Gobbi for pointing these out.

vtkXRenderWindow --> vtkXOpenGLRenderWindow.

This patch adds support for parsing headers that have various features
that were introduced in the C++14 standard:
1) binary literals
2) digit separators in numeric literals
3) variable templates
4) "typename" instead of "class" in templated template parameters

It also introduces a proposed C++17 feature:
5) the u8 prefix for character literals

The wrapper's char literal evaluator did not recognize the 'u' and U'
escape codes or evaluate utf-8 encoded char constants.  Also, the
CPRE_IDGIT character type has been split into CPRE_XID (which allows
non-ASCII chars) and CPRE_XDIGIT (which is restricted to ASCII).

The char pointer was not being advanced, leading to incorrect evaluation
and a false syntax error.  Also, octal and hexadecimal escape codes were
not evaluated with the correct signedness.

Most C++ compilers have either a __restrict or __restrict__ keyword
that serves the same purpose as the C99 "restrict" keyword.  The
wrapper parser can safely ignore this keyword.

This is for code where the typedef modifier does not come first, e.g.
    struct { ... } typedef mytype;
It causes such typefs to be ignored because vtkParse.y is currently
unable to properly deal with anonymous structs.  Note that the more
common "typedef struct { ... } mytype;" is already treated the same.

The Python vtk module was failing to import the installed extension
modules with Python 3, because relative imports now require a leading
".".   This problem did not show up on the dashboard, because the
dash builds run their tests on the build directory (where the vtkpython
executable has a baked-in PYTHONPATH) but not on the installed programs
and modules.

The try/except used in this patch is not an ideal solution, and I would
rather that the extension modules were placed in Wrapping/Python/vtk/
during the build, but the required Build/Debug subdirs for Visual Studio
make that impossible.

In Python 3.5, they finally created a public function to convert
strings from local encoding to wchar_t unicode.  The old internal
function _Py_char2wchar() has been replaced by Py_DecodeLocale(),
which also handles UTF-16 surrogates for OS X.

The "special type" wrapping for abstract classes was disabled, making
it impossible to define non-concrete base classes for special types.

This makes the python wrappers ignore WRAP_EXCLUDE, and instead use
the new property WRAP_EXCLUDE_PYTHON that excludes fewer classes.
The WRAP_SPECIAL flag, which used to act as a whitelist for python,
has been removed.

Because this change causes classes to be wrapped in python by default,
some third-party VTK packages might break until they modify their own
CMakeLists.txt files to add WRAP_EXCLUDE_PYTHON where necessary.

Previously, it only checked whether the entire line in the file was
unique.  Instead, it should verify that the entry itself is unique.
This became an issue in some C headers that had declarations of the
form "typedef struct X {} X;", causing X to appear both as a typedef
and as a class type.

The python wrappers cannot successfully wrap a C++ stream operator
if the second parameter (i.e. the object to be printed) is a non-const
reference.