[vtkusers] VTK Python3 support
Andrew Maclean
andrew.amaclean at gmail.com
Tue Mar 10 18:38:14 EDT 2015
Let me know if I can help. I have Anaconda Python installed for windows
which is great because it includes numpy, scipy etc.
One thing Anaconda Python does is that it allows the user to change
environments so that python can refer to either python 2.7.8 or python 3.4
depending upon the environment.
find_package(PythonInterp 3)
find_package(PythonLibs 3)
Will not find the 3.4 if your default is 2.7.8. So I guess you will have to
set the default path to the 3.4 version. Not a great hardship but worth
noting.
Anaconda Python can also install in the user's home directory. The VTK
version of FindPythonLibs.cmake (which is old) will not pick up the lib and
include path in this case. I thought of removing this file entirely and
using the CMake one. Is this Ok?
In vtkPythonWrapping.cmake there is a plethora (love that word!) of python
variables e.g PYTHON_VERSION_MAJOR, PYTHON_VERSION_MINOR from the Cmake
version of FindPythonInterp.cmake and PYTHON_MAJOR_VERSION,
PYTHON_MINOR_VERSION, PYTHON_MICRO_VERSION from the VTK version of
FindPythonLibs.cmake. I believe that that section of code building up
to if(NOT ${_interp_version} STREQUAL ${_libs_version}) could be simplified
by just comparing PYTHON_VERSION_STRING and PYTHONLIBS_VERSION_STRING. The
only issue I see is in Utilities/Python/vtkPythonConfigure.h.in. Given that
we have already compared the library and executable version in
vtkPythonWrapping.cmake. Would it be safe to use:
./Utilities/Python/vtkPythonConfigure.h.in:#define VTK_PYTHON_VERSION_HEX
((@PYTHON_VERSION_MAJOR@ << 24) | (@PYTHON_VERSION_MINOR@ << 16) | (@
PYTHON_VERSION_PATCH@ << 8))
instead of:
./Utilities/Python/vtkPythonConfigure.h.in:#define VTK_PYTHON_VERSION_HEX
((@PYT
HON_MAJOR_VERSION@ << 24) | (@PYTHON_MINOR_VERSION@ << 16) |
(@PYTHON_MICRO_VERSION@ << 8))
here?
Let me know what you think.
Regards
Andrew
> ---------- Forwarded message ----------
> From: Berk Geveci <berk.geveci at kitware.com>
> To: Arnd Baecker <arnd.baecker at web.de>
> Cc: David Gobbi <david.gobbi at gmail.com>, "vtkusers at vtk.org" <
> vtkusers at vtk.org>
> Date: Tue, 10 Mar 2015 07:55:02 -0400
> Subject: Re: [vtkusers] VTK Python3 support
> Hi Arnd,
>
> Your assessment sounds in the right ballpark. I don't foresee more issues.
> In fact, most of the Python code in VTK is in the testing suite. I'd hope
> that any errors there would be caught easily. The huge majority of
> non-testing Python code is in Wrapping/Python/vtk, which is something like
> 40 files. I volunteer taking care of most of those files. I am pretty sure
> that we can find volunteers to fix the tests. So upgrading the Python files
> is really not that hard. Wrapping is the main challenge.
>
> Best,
> -berk
>
>
> On Tue, Mar 10, 2015 at 3:45 AM, Arnd Baecker <arnd.baecker at web.de> wrote:
>
>> As a follow-up concerning the conversion of the .py files:
>> I have run the current 6.2 release through pylint
>> with --py3k option.
>>
>> Excluding everything from the ThirdParty directory
>> (which for example contains Twisted 14.0.0 which
>> is not yet ported to Python 3)
>> this is only approx 780 python files.
>>
>> One gets a total of 3130 violations spread over 745 files.
>>
>> Out of these there are:
>> - 2325 violations W1618
>> (missing `from __future__ import absolute_import`)
>> Adding this line actually might not be necessary, it just indicates
>> that this behaviour is the default on python 3.
>> - 552 violations E1601
>> print statement.
>> This can be easily solved using
>> from __future__ import print_function
>> and converting all print-statements to print(...)
>> - 53 violations E1604
>> syntax change in raise
>>
>> So this leaves some further 200 violations spread over 72 files.
>> These have to be looked at individually.
>> Several warn about the change in division
>> (which can be solved using ``from __future__ import division``
>> and using // instead of the current usage of /.
>>
>> Overall that part seems doable with reasonable effort
>> (But maybe I am seeing things too optimistic
>> or I am overlooking something ...).
>> In the end this would mean that all examples and tests
>> could (in principle) be run both on python 2 and python 3
>> without any further code changes.
>> Moreover, ThirdParty already contains SixPython
>> which could be used if there are changes like range vs. xrange etc.
>>
>> Are there automatic tests runs
>> a) for the python code?
>> b) to determine code-coverage for VTK
>> (including the python side)?
>> This would help to prevent any regression
>> during the above steps.
>>
>> Concerning the first two points of David:
>>
>>> 1) VTK wrapping still uses old-style classes. I've been meaning to fix
>>> this.
>>> 2) Basic compile issues and cross-compatibility for py3 and py2 -
>>> we received a patch that fixes some of these issues.
>>>
>> I have no clue how much work this is...
>>
>> Best, Arnd
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>
>
> ---------- Forwarded message ----------
> From: David Gobbi <david.gobbi at gmail.com>
> To: -Daniel- <ich_daniel at habmalnefrage.de>
> Cc: VTK Users <vtkusers at vtk.org>
> Date: Tue, 10 Mar 2015 06:52:47 -0600
> Subject: Re: [vtkusers] VTK+GDCM+JAVA error in CMake
> Hi Daniel,
>
> There isn't any support for surface segmentation objects in vtk-dicom. It
> is only
> able to generate DICOM data sets for images.
>
> - David
>
> On Tue, Mar 10, 2015 at 4:53 AM, -Daniel- <ich_daniel at habmalnefrage.de>
> wrote:
>
>> I try it again.
>>
>> Unfortunately I have received no info from the GDCM community. I don't
>> know
>> where I can add the variable.
>> Now I'm trying to vtk-dicom.
>> Is there a simple example to write an STL object in the DICOM format?
>
>
>
>
> ---------- Forwarded message ----------
> From: Doug Hoppes <dhoppes at mbfbioscience.com>
> To: "vtkusers at vtk.org" <vtkusers at vtk.org>
> Cc:
> Date: Tue, 10 Mar 2015 12:53:40 +0000
> Subject: [vtkusers] how to join triangles into a smooth surface
>
> Hey all,
>
>
>
> I have two cylinders that are joined at a 60 degree angle
> from each other. Ideally, I would love for the actors to join seamlessly
> as one surface. Essentially, I’m looking for a way to do it that looks
> like a metanurb or nurb surface or a really smooth isosurface. Is there a
> way to do this?
>
>
>
> Doug
>
>
>
>
> ---------- Forwarded message ----------
> From: David Gobbi <david.gobbi at gmail.com>
> To: "vtkusers at vtk.org" <vtkusers at vtk.org>
> Cc:
> Date: Tue, 10 Mar 2015 07:37:42 -0600
> Subject: Re: [vtkusers] VTK Python3 support
> Hi All,
>
> I think that it is a very good point that py3k support is needed in
> order for vtk-python to move forward as a teaching tool for new
> students. We're actually very lucky that the scientific computing
> community has decided to stick with python, because moving
> to a whole new language would be _really_ tough.
>
> As far as the wrappers go, currently the C++ PyVTKClass and
> PyVTKObject extension types provide an old-style (python 1.5)
> metaclass mechanism. Moving forward, each VTK class can
> be its own extension type... I looked at the wrapper code over
> the weekend, and it's a few days' work that I can probably get
> done sometime in May or June.
>
> After that, the wrappers will have to be modified to handle the
> changes that py3k made to PyInt and PyLong, and then all the
> necessary #ifdefs will have to be added so that both py2 and
> py3k versions of the wrappers will compile.
>
> Fortunately, VTK has an abundance of python tests, including
> many tests in Common/Core/Testing/Python for special features
> of the wrappers. So I don't think we're likely to break anything
> (e.g. numpy support) in the transition.
>
> - David
>
> On Tue, Mar 10, 2015 at 5:55 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi Arnd,
>>
>> Your assessment sounds in the right ballpark. I don't foresee more
>> issues. In fact, most of the Python code in VTK is in the testing suite.
>> I'd hope that any errors there would be caught easily. The huge majority of
>> non-testing Python code is in Wrapping/Python/vtk, which is something like
>> 40 files. I volunteer taking care of most of those files. I am pretty sure
>> that we can find volunteers to fix the tests. So upgrading the Python files
>> is really not that hard. Wrapping is the main challenge.
>>
>> Best,
>> -berk
>>
>>
>> On Tue, Mar 10, 2015 at 3:45 AM, Arnd Baecker <arnd.baecker at web.de>
>> wrote:
>>
>>> As a follow-up concerning the conversion of the .py files:
>>> I have run the current 6.2 release through pylint
>>> with --py3k option.
>>>
>>> Excluding everything from the ThirdParty directory
>>> (which for example contains Twisted 14.0.0 which
>>> is not yet ported to Python 3)
>>> this is only approx 780 python files.
>>>
>>> One gets a total of 3130 violations spread over 745 files.
>>>
>>> Out of these there are:
>>> - 2325 violations W1618
>>> (missing `from __future__ import absolute_import`)
>>> Adding this line actually might not be necessary, it just indicates
>>> that this behaviour is the default on python 3.
>>> - 552 violations E1601
>>> print statement.
>>> This can be easily solved using
>>> from __future__ import print_function
>>> and converting all print-statements to print(...)
>>> - 53 violations E1604
>>> syntax change in raise
>>>
>>> So this leaves some further 200 violations spread over 72 files.
>>> These have to be looked at individually.
>>> Several warn about the change in division
>>> (which can be solved using ``from __future__ import division``
>>> and using // instead of the current usage of /.
>>>
>>> Overall that part seems doable with reasonable effort
>>> (But maybe I am seeing things too optimistic
>>> or I am overlooking something ...).
>>> In the end this would mean that all examples and tests
>>> could (in principle) be run both on python 2 and python 3
>>> without any further code changes.
>>> Moreover, ThirdParty already contains SixPython
>>> which could be used if there are changes like range vs. xrange etc.
>>>
>>> Are there automatic tests runs
>>> a) for the python code?
>>> b) to determine code-coverage for VTK
>>> (including the python side)?
>>> This would help to prevent any regression
>>> during the above steps.
>>>
>>> Concerning the first two points of David:
>>>
>>>> 1) VTK wrapping still uses old-style classes. I've been meaning to fix
>>>> this.
>>>> 2) Basic compile issues and cross-compatibility for py3 and py2 -
>>>> we received a patch that fixes some of these issues.
>>>>
>>> I have no clue how much work this is...
>>>
>>> Best, Arnd
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: Sean McBride <sean at rogue-research.com>
> To: Andy Somogyi <andy.somogyi at gmail.com>, <vtkusers at vtk.org>
> Cc:
> Date: Tue, 10 Mar 2015 10:43:04 -0400
> Subject: Re: [vtkusers] Building Cocoa example on OSX
> On Mon, 9 Mar 2015 21:53:10 -0400, Andy Somogyi said:
>
> >This question has been asked before, but I’ve not seen any resolution.
> >
> >I’m trying the build a Cocoa example on OSX 10.9, and I get the
> >Undefined symbols for architecture x86_64:
> >
> >"_OBJC_CLASS_$_vtkCocoaGLView", referenced from:
> > _OBJC_CLASS_$_BasicVTKView in BasicVTKView.o
> >"_OBJC_METACLASS_$_vtkCocoaGLView", referenced from:
> > _OBJC_METACLASS_$_BasicVTKView in BasicVTKView.o
>
> The SimpleCocoaVTK example? Are you trying to build it from it's Xcode
> project or with CMake? In any case, IIRC, it was broken for a while but
> fixed in git master months ago. Could you try VTK 6.2?
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng sean at rogue-research.com
> Rogue Research www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
--
___________________________________________
Andrew J. P. Maclean
___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150311/aec1ee01/attachment.html>
More information about the vtkusers
mailing list