From david.thompson at kitware.com Wed Apr 4 12:48:51 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 12:48:51 -0400 Subject: [Smtk-developers] Homebrew Python Message-ID: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> Hi all, For those of you using homebrew python to build SMTK/CMB, be aware that "brew upgrade" will switch to python3, which causes build problems[1] at the moment. David [1]: CMake Error at /pulsar/build/cmb/superbuild/superbuild/paraview/src/VTK/CMake/FindPythonLibs.cmake:183 (FILE): FILE STRINGS file "/usr/local/Frameworks/Python.framework/Headers/patchlevel.h" cannot be read. Call Stack (most recent call first): thirdparty/smtk/CMakeLists.txt:325 (find_package) CMake Error at /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find PythonInterp: Found unsuitable version "1.4", but required is at least "2.7" (found /usr/local/bin/python2.7) Call Stack (most recent call first): /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:375 (_FPHSA_FAILURE_MESSAGE) /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPythonInterp.cmake:152 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) thirdparty/smtk/CMakeLists.txt:326 (find_package) From david.thompson at kitware.com Wed Apr 4 13:13:00 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 13:13:00 -0400 Subject: [Smtk-developers] Homebrew Python In-Reply-To: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> References: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> Message-ID: <1AADF821-4BF4-4917-B8A0-FFF553D0BEF6@kitware.com> > For those of you using homebrew python to build SMTK/CMB, be aware that "brew upgrade" will switch to python3, which causes build problems[1] at the moment. If you already had a homebrew python2 built, a workaround is to "brew switch python 2.7.14" (or whatever version you have). If you don't already have a homebrew python, I guess the workaround is to use the superbuild's python. But really we should get SMTK working with Python 3. I had it at least compiling a few months back but the ParaView python changes appear to have caused some configuration failures. David > [1]: > CMake Error at /pulsar/build/cmb/superbuild/superbuild/paraview/src/VTK/CMake/FindPythonLibs.cmake:183 (FILE): > FILE STRINGS file > "/usr/local/Frameworks/Python.framework/Headers/patchlevel.h" cannot be > read. > Call Stack (most recent call first): > thirdparty/smtk/CMakeLists.txt:325 (find_package) > > > CMake Error at /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): > Could NOT find PythonInterp: Found unsuitable version "1.4", but required > is at least "2.7" (found /usr/local/bin/python2.7) > Call Stack (most recent call first): > /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:375 (_FPHSA_FAILURE_MESSAGE) > /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPythonInterp.cmake:152 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > thirdparty/smtk/CMakeLists.txt:326 (find_package) > From david.thompson at kitware.com Wed Apr 4 13:14:36 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 13:14:36 -0400 Subject: [Smtk-developers] Discourse Message-ID: Hi all, Since I'm spamming you about python, I might as well ask whether anyone wants to try discourse out as an alternative to the mailing list. VTK and ParaView are both switching over in the near future. We could try it out on discourse.kitware.com if people are interested. David From haocheng.liu at kitware.com Wed Apr 4 13:18:14 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 4 Apr 2018 13:18:14 -0400 Subject: [Smtk-developers] Discourse In-Reply-To: References: Message-ID: Hi David, Is discourse compatible with the mailing list (Let's take Gitlab as an example, I can reply to other people's comments or call command via email and all discussions are formatted nicely in a forum format)? On Wed, Apr 4, 2018 at 1:14 PM, David Thompson wrote: > Hi all, > > Since I'm spamming you about python, I might as well ask whether anyone > wants to try discourse out as an alternative to the mailing list. VTK and > ParaView are both switching over in the near future. We could try it out on > discourse.kitware.com if people are interested. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Wed Apr 4 13:19:18 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 4 Apr 2018 13:19:18 -0400 Subject: [Smtk-developers] Homebrew Python In-Reply-To: <1AADF821-4BF4-4917-B8A0-FFF553D0BEF6@kitware.com> References: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> <1AADF821-4BF4-4917-B8A0-FFF553D0BEF6@kitware.com> Message-ID: <6F4010D5-95BB-4B64-98FA-2BB64480324E@kitware.com> > If you don't already have a homebrew python, I guess the workaround is to use the superbuild's python. I don?t think the superbuild builds a python on OS X. > On Apr 4, 2018, at 1:13 PM, David Thompson wrote: > >> For those of you using homebrew python to build SMTK/CMB, be aware that "brew upgrade" will switch to python3, which causes build problems[1] at the moment. > > If you already had a homebrew python2 built, a workaround is to "brew switch python 2.7.14" (or whatever version you have). > > If you don't already have a homebrew python, I guess the workaround is to use the superbuild's python. But really we should get SMTK working with Python 3. I had it at least compiling a few months back but the ParaView python changes appear to have caused some configuration failures. > > David > > >> [1]: >> CMake Error at /pulsar/build/cmb/superbuild/superbuild/paraview/src/VTK/CMake/FindPythonLibs.cmake:183 (FILE): >> FILE STRINGS file >> "/usr/local/Frameworks/Python.framework/Headers/patchlevel.h" cannot be >> read. >> Call Stack (most recent call first): >> thirdparty/smtk/CMakeLists.txt:325 (find_package) >> >> >> CMake Error at /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): >> Could NOT find PythonInterp: Found unsuitable version "1.4", but required >> is at least "2.7" (found /usr/local/bin/python2.7) >> Call Stack (most recent call first): >> /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:375 (_FPHSA_FAILURE_MESSAGE) >> /usr/local/Cellar/cmake/3.9.2/share/cmake/Modules/FindPythonInterp.cmake:152 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) >> thirdparty/smtk/CMakeLists.txt:326 (find_package) >> > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > https://smtk.org/mailman/listinfo/smtk-developers From david.thompson at kitware.com Wed Apr 4 13:20:47 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 13:20:47 -0400 Subject: [Smtk-developers] Homebrew Python In-Reply-To: <6F4010D5-95BB-4B64-98FA-2BB64480324E@kitware.com> References: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> <1AADF821-4BF4-4917-B8A0-FFF553D0BEF6@kitware.com> <6F4010D5-95BB-4B64-98FA-2BB64480324E@kitware.com> Message-ID: <80B6D1DA-C808-4B2F-AF93-5B3F9A818287@kitware.com> >> If you don't already have a homebrew python, I guess the workaround is to use the superbuild's python. > > I don?t think the superbuild builds a python on OS X. Can't or doesn't by default? David From david.thompson at kitware.com Wed Apr 4 13:21:47 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 13:21:47 -0400 Subject: [Smtk-developers] Discourse In-Reply-To: References: Message-ID: > Is discourse compatible with the mailing list (Let's take Gitlab as an example, I can reply to other people's comments or call command via email and all discussions are formatted nicely in a forum format)? Discourse has a "mailing list mode" (which each user can set) that lets you work this way. I have not tried it out. David From tj.corona at kitware.com Wed Apr 4 13:24:57 2018 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 4 Apr 2018 13:24:57 -0400 Subject: [Smtk-developers] Homebrew Python In-Reply-To: <80B6D1DA-C808-4B2F-AF93-5B3F9A818287@kitware.com> References: <57208586-94BC-4C98-B359-8AC0521D3477@kitware.com> <1AADF821-4BF4-4917-B8A0-FFF553D0BEF6@kitware.com> <6F4010D5-95BB-4B64-98FA-2BB64480324E@kitware.com> <80B6D1DA-C808-4B2F-AF93-5B3F9A818287@kitware.com> Message-ID: <89E03440-5BFE-4584-B87D-2F62B809AE76@kitware.com> > Can't or doesn't by default? Can?t. Cmb-sb/superbuild/projects/apple/python.cmake: superbuild_add_project(python MUST_USE_SYSTEM) > On Apr 4, 2018, at 1:20 PM, David Thompson wrote: > >>> If you don't already have a homebrew python, I guess the workaround is to use the superbuild's python. >> >> I don?t think the superbuild builds a python on OS X. > > Can't or doesn't by default? > > David From haocheng.liu at kitware.com Wed Apr 4 13:24:49 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 4 Apr 2018 13:24:49 -0400 Subject: [Smtk-developers] Discourse In-Reply-To: References: Message-ID: I vote for switching to discourse. As a student, I used to hate mailing list because it's painful to search past discussions and filter out useful info. As a developer, I love mailing list since it frees me from monitoring several posts. If it can do both then it would be awesome! On Wed, Apr 4, 2018 at 1:21 PM, David Thompson wrote: > > Is discourse compatible with the mailing list (Let's take Gitlab as an > example, I can reply to other people's comments or call command via email > and all discussions are formatted nicely in a forum format)? > > Discourse has a "mailing list mode" (which each user can set) that lets > you work this way. I have not tried it out. > > David -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Apr 4 13:34:38 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 13:34:38 -0400 Subject: [Smtk-developers] Discourse In-Reply-To: References: Message-ID: > I vote for switching to discourse. I've e-mailed the sysadmins to create new categories on https://discourse.kitware.com/ for us. If we like it, we can have our own instance(s) at discourse.smtk.org and discourse.computationalmodelbuilder.org . David From david.thompson at kitware.com Wed Apr 4 19:25:42 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 19:25:42 -0400 Subject: [Smtk-developers] Pybind and attribute::ItemDefinition subclasses Message-ID: <3849B19E-47D1-4C0B-AF2A-4E4045961E18@kitware.com> Hi TJ, While working on the great ModelEntityItem purge of 2018, I ran into an issue wrapping its replacement's definition class (ReferenceItemDefinition). It builds but running a python test like unitAttributeBasicsPy causes this failure: ImportError: generic_type: type "ReferenceItemDefinition" does not have a non-default holder type while its base "smtk::attribute::ItemDefinition" does I can get it to run properly if I copy the pattern from ItemDefinition (which creates a PySharedPtrClass instead of a py::class_)... but is this something I should know to do or is there a problem with the ReferenceItemDefinition header that causes the utilities/python/cpp_to_pybind11.py script to barf out brokenness? If the former can we document it somewhere? Thanks, David From tj.corona at kitware.com Wed Apr 4 22:09:45 2018 From: tj.corona at kitware.com (T.J. Corona) Date: Wed, 4 Apr 2018 22:09:45 -0400 Subject: [Smtk-developers] Pybind and attribute::ItemDefinition subclasses In-Reply-To: <3849B19E-47D1-4C0B-AF2A-4E4045961E18@kitware.com> References: <3849B19E-47D1-4C0B-AF2A-4E4045961E18@kitware.com> Message-ID: Hi David, All classes that require the use of shared pointers must also do so in pybind11 (as you discovered). The auto gen script should have done that for you (and It may be documented there). Did you use the script or wrap the class by hand? If the former, then that is indeed a problem with the script (it looks to see if a class inherits from shared_from_this, if memory serves). If the latter, then the pybind11 documentation would have probably gotten you to the answer... Sincerely, T.J. Sent from my iPhone > On Apr 4, 2018, at 7:25 PM, David Thompson wrote: > > Hi TJ, > > While working on the great ModelEntityItem purge of 2018, I ran into an issue wrapping its replacement's definition class (ReferenceItemDefinition). It builds but running a python test like unitAttributeBasicsPy causes this failure: > > ImportError: generic_type: type "ReferenceItemDefinition" does not have a non-default holder type while its base "smtk::attribute::ItemDefinition" does > > I can get it to run properly if I copy the pattern from ItemDefinition (which creates a PySharedPtrClass instead of a py::class_)... but is this something I should know to do or is there a problem with the ReferenceItemDefinition header that causes the utilities/python/cpp_to_pybind11.py script to barf out brokenness? If the former can we document it somewhere? > > Thanks, > David From david.thompson at kitware.com Wed Apr 4 22:36:12 2018 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Apr 2018 22:36:12 -0400 Subject: [Smtk-developers] Pybind and attribute::ItemDefinition subclasses In-Reply-To: References: <3849B19E-47D1-4C0B-AF2A-4E4045961E18@kitware.com> Message-ID: Hi TJ, > All classes that require the use of shared pointers must also do so in pybind11 (as you discovered). The auto gen script should have done that for you (and It may be documented there). Did you use the script or wrap the class by hand? I used the script. > If the former, then that is indeed a problem with the script (it looks to see if a class inherits from shared_from_this, if memory serves). ... The class inherits from a class that inherits shared_from_this. Perhaps that is causing the problem? David From david.thompson at kitware.com Thu Apr 5 10:41:50 2018 From: david.thompson at kitware.com (David Thompson) Date: Thu, 5 Apr 2018 10:41:50 -0400 Subject: [Smtk-developers] Environment management Message-ID: <6ED2D35F-249D-4615-B32D-0D168B598B41@kitware.com> Hi TJ, I'm trying to get tests working as I replace ModelEntityItem with ReferenceItem and have some questions about python tests: Is there a way to import the various environments (smtkOperationEnvironment, etc) in python? I see that "import smtk.environment" exists, but are the registration methods wrapped, or am I expected to use some python dlopen equivalent to load them, or have we just not been there yet? Thanks, David From tj.corona at kitware.com Thu Apr 5 11:01:36 2018 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 5 Apr 2018 11:01:36 -0400 Subject: [Smtk-developers] Environment management In-Reply-To: <6ED2D35F-249D-4615-B32D-0D168B598B41@kitware.com> References: <6ED2D35F-249D-4615-B32D-0D168B598B41@kitware.com> Message-ID: <70E75F04-F840-43F0-83A6-56379606DBEE@kitware.com> Hi David, > Is there a way to import the various environments (smtkOperationEnvironment, etc) in python? There is nothing yet, but that was just an oversight. > are the registration methods wrapped Since access to the singletons in smtk::environment are wrapped, none of the other stuff needs to be. I?ve created a mockup of one way to force the import of a session?s environment, but I?m open to ideas. > am I expected to use some python dlopen equivalent to load them I think the mockup looks a little cleaner to the end-user than dlopen. Sincerely, T.J. > On Apr 5, 2018, at 10:41 AM, David Thompson wrote: > > Hi TJ, > > I'm trying to get tests working as I replace ModelEntityItem with ReferenceItem and have some questions about python tests: > > Is there a way to import the various environments (smtkOperationEnvironment, etc) in python? > > I see that "import smtk.environment" exists, but are the registration methods wrapped, or am I expected to use some python dlopen equivalent to load them, or have we just not been there yet? > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Apr 5 11:22:30 2018 From: david.thompson at kitware.com (David Thompson) Date: Thu, 5 Apr 2018 11:22:30 -0400 Subject: [Smtk-developers] Environment management In-Reply-To: <70E75F04-F840-43F0-83A6-56379606DBEE@kitware.com> References: <6ED2D35F-249D-4615-B32D-0D168B598B41@kitware.com> <70E75F04-F840-43F0-83A6-56379606DBEE@kitware.com> Message-ID: Hi TJ, > ... >> am I expected to use some python dlopen equivalent to load them > > I think the mockup looks a little cleaner to the end-user than dlopen. I've commented on the mockup[1], but to expand a bit here... there's a lot of boilerplate code for both the environment and its C++ wrapper that belongs in a CMake macro. But otherwise, I much prefer your mockup to the vagaries of Python ctypes (which appears to be the recommended dlopen interface in Python). David [1]: https://gitlab.kitware.com/cmb/smtk/merge_requests/1095/diffs From david.thompson at kitware.com Fri Apr 6 15:27:34 2018 From: david.thompson at kitware.com (David Thompson) Date: Fri, 6 Apr 2018 15:27:34 -0400 Subject: [Smtk-developers] Discourse In-Reply-To: References: Message-ID: Hi all, We now have a category for SMTK: https://discourse.kitware.com/c/smtk and CMB: https://discourse.kitware.com/c/cmb on Kitware's discourse server. Please consider giving them a try! Thanks, David > On Apr 4, 2018, at 13:34, David Thompson wrote: > >> I vote for switching to discourse. > > I've e-mailed the sysadmins to create new categories on https://discourse.kitware.com/ for us. If we like it, we can have our own instance(s) at discourse.smtk.org and discourse.computationalmodelbuilder.org . > > David From david.thompson at kitware.com Tue Apr 10 14:33:31 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 10 Apr 2018 14:33:31 -0400 Subject: [Smtk-developers] Release notes Message-ID: <0E3626D3-64C8-4D21-8F71-2CF995AC4F38@kitware.com> New topic on our Discourse server: https://discourse.kitware.com/t/release-notes/84?u=dcthomp David From david.thompson at kitware.com Tue Apr 10 16:27:16 2018 From: david.thompson at kitware.com (David Thompson) Date: Tue, 10 Apr 2018 16:27:16 -0400 Subject: [Smtk-developers] Operations based on a selection Message-ID: <7210E441-AA11-49D7-B42F-DA8E1BA5CF77@kitware.com> New topic on our Discourse server: https://discourse.kitware.com/t/operations-based-on-a-selection/87?u=dcthomp David From david.thompson at kitware.com Mon Apr 23 15:01:07 2018 From: david.thompson at kitware.com (David Thompson) Date: Mon, 23 Apr 2018 15:01:07 -0400 Subject: [Smtk-developers] Operator views Message-ID: New topic on our Discourse server: https://discourse.kitware.com/t/operation-view/94 David