From bob.obara at kitware.com Wed Oct 4 11:19:16 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 4 Oct 2017 10:19:16 -0500 Subject: [Smtk-developers] Operator View Change Message-ID: Hi All, By default all View will show category and advance level filtering - though this behavior makes sense for simulation-input Views, Operator Views rarely (if ever) have category information and many don?t have advance items. So I propose the Operator View has those off by default and if the specific operator wants to enable these item filters, they can turn them on in their sbt file. I?ve made the change but will hold off the commit until this evening so people can weigh in. Comments? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Wed Oct 4 12:01:18 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 4 Oct 2017 12:01:18 -0400 Subject: [Smtk-developers] Operator View Change In-Reply-To: References: Message-ID: +1 Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On Oct 4, 2017, at 11:19 AM, Bob Obara wrote: > > Hi All, > > By default all View will show category and advance level filtering - though this behavior makes sense for simulation-input Views, Operator Views rarely (if ever) have category information and many don?t have advance items. So I propose the Operator View has those off by default and if the specific operator wants to enable these item filters, they can turn them on in their sbt file. > > I?ve made the change but will hold off the commit until this evening so people can weigh in. > > Comments? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Oct 4 12:45:10 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 4 Oct 2017 12:45:10 -0400 Subject: [Smtk-developers] Operator View Change In-Reply-To: References: Message-ID: <170C3821-F570-47A2-BD7F-A76C144C7D6F@kitware.com> > By default all View will show category and advance level filtering - though this behavior makes sense for simulation-input Views, Operator Views rarely (if ever) have category information and many don?t have advance items. So I propose the Operator View has those off by default and if the specific operator wants to enable these item filters, they can turn them on in their sbt file. > > ... Comments? +1, too. David From tj.corona at kitware.com Tue Oct 10 08:41:18 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 10 Oct 2017 08:41:18 -0400 Subject: [Smtk-developers] TalosIV is still offline Message-ID: <3A9F418F-74DF-42FD-BFCF-8EA9E2FF4883@kitware.com> Hi all, Yesterday morning I rebooted TalosIV, but it looks like that didn?t bring it back online. I am logged into the Dashboard user and I tried enabling the buildbot_slave through the LaunchControl app but no dice. How do I reenable TalosIV as a buildbot? Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Oct 10 09:24:33 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 10 Oct 2017 09:24:33 -0400 Subject: [Smtk-developers] TalosIV is still offline In-Reply-To: <3A9F418F-74DF-42FD-BFCF-8EA9E2FF4883@kitware.com> References: <3A9F418F-74DF-42FD-BFCF-8EA9E2FF4883@kitware.com> Message-ID: <20171010132433.GA18072@megas.kitware.com> On Tue, Oct 10, 2017 at 08:41:18 -0400, TJ Corona wrote: > Yesterday morning I rebooted TalosIV, but it looks like that didn?t > bring it back online. I am logged into the Dashboard user and I tried > enabling the buildbot_slave through the LaunchControl app but no dice. > How do I reenable TalosIV as a buildbot? That service is it?anything interesting from twistd.log? --Ben From david.thompson at kitware.com Thu Oct 12 13:59:33 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 12 Oct 2017 13:59:33 -0400 Subject: [Smtk-developers] nlohmann_json Message-ID: Hi Bob et al., You had asked for a test of nlohmann_json building+running on windows before we went further. Here: https://gitlab.kitware.com/dcthomp/smtk/blob/test-nlohmann-json/smtk/io/testing/cxx/jsonTest.cxx is a small test that creates a model in SMTK, converts it to JSON, and prints it out. I submitted a MR[1] and you can see the CDash results of jsonTest if you are curious: + linux jsonTest output: https://open.cdash.org/testDetails.php?test=591660999&build=5100141 + macOS jsonTest output: https://open.cdash.org/testDetails.php?test=591661562&build=5100140 + windows jsonTest output: https://open.cdash.org/testDetails.php?test=591665277&build=5100142 David [1]: https://gitlab.kitware.com/cmb/smtk/merge_requests/905 From bob.obara at kitware.com Sat Oct 14 19:47:36 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sat, 14 Oct 2017 19:47:36 -0400 Subject: [Smtk-developers] Saturday gallifrey build Message-ID: Hi All, The experimental dashboard was using the latest paraview master and qt 5.9.2. Bob Sent from my iPad From tj.corona at kitware.com Tue Oct 17 12:20:00 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 17 Oct 2017 11:20:00 -0500 Subject: [Smtk-developers] TalosIV GLEW issue Message-ID: <9E48911E-0047-487E-881D-40329D6E3A9C@kitware.com> Hi all, Would someone mind checking on TalosIV? The following familiar error is cropping up during dashboard testing: ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 785 vtkCocoaRenderWindow (0x7f97c30da400): GLEW could not be initialized. Thanks! Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue Oct 17 12:46:21 2017 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 17 Oct 2017 12:46:21 -0400 Subject: [Smtk-developers] TalosIV GLEW issue In-Reply-To: <9E48911E-0047-487E-881D-40329D6E3A9C@kitware.com> References: <9E48911E-0047-487E-881D-40329D6E3A9C@kitware.com> Message-ID: Try it now ? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Oct 17, 2017, at 12:20 PMEDT, TJ Corona wrote: > > Hi all, > > Would someone mind checking on TalosIV? The following familiar error is cropping up during dashboard testing: > > ERROR: In /Users/dashboard/Dashboards/buildbot/smtk-talosiv-osx-shared-release_cgm_superbuild/build/superbuild/paraview/src/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx, line 785 > vtkCocoaRenderWindow (0x7f97c30da400): GLEW could not be initialized. > Thanks! > > Sincerely, > T.J. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue Oct 24 16:13:45 2017 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 24 Oct 2017 16:13:45 -0400 Subject: [Smtk-developers] Issue Building SMTK release Message-ID: <77B6F3FC-D2FC-401D-84C7-B200EA7EB207@kitware.com> Hi All, When I try building the SMTK release branch I get: [1/486] Building CXX object smtk/mesh/testing/cxx/CMakeFiles/TestInterpolateOntoMesh.dir/TestInterpolateOntoMesh.cxx.o FAILED: smtk/mesh/testing/cxx/CMakeFiles/TestInterpolateOntoMesh.dir/TestInterpolateOntoMesh.cxx.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DSMTK_SCRATCH_DIR=\"/Users/obara/Projects/Kitware/Builds/CMBSuperBuildRelease/superbuild/smtk/build/Testing/Temporary\" -I. -I/Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK -isystem /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/thirdparty -isystem thirdparty -isystem /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/thirdparty/cJSON -isystem /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/thirdparty/pugixml -isystem /Users/obara/Projects/Kitware/Builds/CMBSuperBuildRelease/install/include -I/Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/thirdparty/moab/src -Ithirdparty/moab/src -fPIC -mmacosx-version-min=10.12 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -Wno-inconsistent-missing-override -std=c++11 -stdlib=libc++ -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -std=gnu++11 -MD -MT smtk/mesh/testing/cxx/CMakeFiles/TestInterpolateOntoMesh.dir/TestInterpolateOntoMesh.cxx.o -MF smtk/mesh/testing/cxx/CMakeFiles/TestInterpolateOntoMesh.dir/TestInterpolateOntoMesh.cxx.o.d -o smtk/mesh/testing/cxx/CMakeFiles/TestInterpolateOntoMesh.dir/TestInterpolateOntoMesh.cxx.o -c /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/smtk/mesh/testing/cxx/TestInterpolateOntoMesh.cxx /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/smtk/mesh/testing/cxx/TestInterpolateOntoMesh.cxx:316:7: error: use of undeclared identifier 'interpolateMeshOpResult'; did you mean 'interpolateOntoMeshOpResult'? if (interpolateMeshOpResult->findInt("outcome")->value() != smtk::model::OPERATION_SUCCEEDED) ^~~~~~~~~~~~~~~~~~~~~~~ interpolateOntoMeshOpResult /Users/obara/Projects/Kitware/CMBRelease/ThirdParty/SMTK/smtk/mesh/testing/cxx/TestInterpolateOntoMesh.cxx:307:31: note: 'interpolateOntoMeshOpResult' declared here smtk::model::OperatorResult interpolateOntoMeshOpResult = interpolateOntoMeshOp->operate(); ^ Whats up? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue Oct 24 16:26:53 2017 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 24 Oct 2017 16:26:53 -0400 Subject: [Smtk-developers] Problem building CMB on Release Message-ID: <789017DC-91AA-47CF-9350-DFD42BB0FAAA@kitware.com> Hi All, When I try to build CMB on the release branch I get the following: /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:142:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' color = smtk::extension::QEntityItemModel::defaultEntityColor("Face"); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:147:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' color = smtk::extension::QEntityItemModel::defaultEntityColor("Edge"); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:152:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' color = smtk::extension::QEntityItemModel::defaultEntityColor("Vertex"); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ Whats up?? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Tue Oct 24 18:04:15 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 24 Oct 2017 18:04:15 -0400 Subject: [Smtk-developers] Problem building CMB on Release In-Reply-To: <789017DC-91AA-47CF-9350-DFD42BB0FAAA@kitware.com> References: <789017DC-91AA-47CF-9350-DFD42BB0FAAA@kitware.com> Message-ID: Hi Bob, On Tue, Oct 24, 2017 at 4:26 PM, Bob Obara wrote: > Hi All, > > When I try to build CMB on the release branch I get the following: > > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/ > pqCMBContextMenuHelper.cxx:142:50: error: no member named > 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel:: > defaultEntityColor("Face"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/ > pqCMBContextMenuHelper.cxx:147:50: error: no member named > 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel:: > defaultEntityColor("Edge"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/ > pqCMBContextMenuHelper.cxx:152:50: error: no member named > 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel:: > defaultEntityColor("Vertex"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > > Whats up?? > > Sincerely sorry, it's my bad. When solving conflicts on release branch, I added master branch code( default color) into it. Here is the fix MR: https://gitlab.kitware.com/cmb/cmb/merge_requests/548. > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 <(518)%20881-4931> > > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/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 haocheng.liu at kitware.com Tue Oct 24 18:24:15 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 24 Oct 2017 18:24:15 -0400 Subject: [Smtk-developers] Problem building CMB on Release In-Reply-To: References: <789017DC-91AA-47CF-9350-DFD42BB0FAAA@kitware.com> Message-ID: Merged. Would you please try to build it again? On Tue, Oct 24, 2017 at 6:04 PM, Haocheng Liu wrote: > Hi Bob, > > On Tue, Oct 24, 2017 at 4:26 PM, Bob Obara wrote: > >> Hi All, >> >> When I try to build CMB on the release branch I get the following: >> >> /Users/obara/Projects/Kitware/CMBRelease/Source/Applications >> /ModelBuilder/pqCMBContextMenuHelper.cxx:142:50: error: no member named >> 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' >> color = smtk::extension::QEntityItemMo >> del::defaultEntityColor("Face"); >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ >> /Users/obara/Projects/Kitware/CMBRelease/Source/Applications >> /ModelBuilder/pqCMBContextMenuHelper.cxx:147:50: error: no member named >> 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' >> color = smtk::extension::QEntityItemMo >> del::defaultEntityColor("Edge"); >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ >> /Users/obara/Projects/Kitware/CMBRelease/Source/Applications >> /ModelBuilder/pqCMBContextMenuHelper.cxx:152:50: error: no member named >> 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' >> color = smtk::extension::QEntityItemModel::defaultEntityColor(" >> Vertex"); >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ >> >> Whats up?? >> >> Sincerely sorry, it's my bad. When solving conflicts on release branch, I > added master branch code( default color) into it. > Here is the fix MR: https://gitlab.kitware.com/cmb/cmb/merge_requests/548. > >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 <(518)%20881-4931> >> >> >> >> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/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> > -- 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 bob.obara at kitware.com Tue Oct 24 22:01:19 2017 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 24 Oct 2017 22:01:19 -0400 Subject: [Smtk-developers] Problem building CMB on Release In-Reply-To: References: <789017DC-91AA-47CF-9350-DFD42BB0FAAA@kitware.com> Message-ID: <43C90099-F628-49D1-A35F-76B836123B25@kitware.com> Thanks Haocheng! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Oct 24, 2017, at 6:24 PMEDT, Haocheng Liu wrote: > > Merged. Would you please try to build it again? > > On Tue, Oct 24, 2017 at 6:04 PM, Haocheng Liu > wrote: > Hi Bob, > > On Tue, Oct 24, 2017 at 4:26 PM, Bob Obara > wrote: > Hi All, > > When I try to build CMB on the release branch I get the following: > > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:142:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel::defaultEntityColor("Face"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:147:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel::defaultEntityColor("Edge"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > /Users/obara/Projects/Kitware/CMBRelease/Source/Applications/ModelBuilder/pqCMBContextMenuHelper.cxx:152:50: error: no member named 'defaultEntityColor' in 'smtk::extension::QEntityItemModel' > color = smtk::extension::QEntityItemModel::defaultEntityColor("Vertex"); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ > > Whats up?? > > Sincerely sorry, it's my bad. When solving conflicts on release branch, I added master branch code( default color) into it. > Here is the fix MR: https://gitlab.kitware.com/cmb/cmb/merge_requests/548 . > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/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 > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue Oct 24 22:04:12 2017 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 24 Oct 2017 22:04:12 -0400 Subject: [Smtk-developers] The more complicated backport format Message-ID: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> Hi Ben, So I have an example of a branch based on release that needed to be merged onto a branch based on master due to merge conflicts - what is the format for the backport? Thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Oct 25 09:04:11 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Oct 2017 09:04:11 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> Message-ID: <20171025130411.GB5635@megas.kitware.com> On Tue, Oct 24, 2017 at 22:04:12 -0400, Bob Obara wrote: > So I have an example of a branch based on release that needed to be > merged onto a branch based on master due to merge conflicts - what is > the format for the backport? It is one of these cases: https://gitlab.kitware.com/utils/git-workflow/wikis/Backport-topics#fixing-both-with-conflicts --Ben From bob.obara at kitware.com Wed Oct 25 09:44:28 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 25 Oct 2017 09:44:28 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <20171025130411.GB5635@megas.kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> Message-ID: <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> Thanks Ben, I think there maybe an issue when testing merge requests w/r to release - can you checkout the experimental merge request builds for Inheriting association info on master and let me know if I?m doing something wrong? Thanks! Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Oct 25, 2017, at 9:04 AMEDT, Ben Boeckel wrote: > > On Tue, Oct 24, 2017 at 22:04:12 -0400, Bob Obara wrote: >> So I have an example of a branch based on release that needed to be >> merged onto a branch based on master due to merge conflicts - what is >> the format for the backport? > > It is one of these cases: > > https://gitlab.kitware.com/utils/git-workflow/wikis/Backport-topics#fixing-both-with-conflicts > > --Ben From ben.boeckel at kitware.com Wed Oct 25 10:24:10 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Oct 2017 10:24:10 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> Message-ID: <20171025142410.GA29522@megas.kitware.com> On Wed, Oct 25, 2017 at 09:44:28 -0400, Bob Obara wrote: > I think there maybe an issue when testing merge requests w/r to > release - can you checkout the experimental merge request builds for > Inheriting association info on master and let me know if I?m doing > something wrong? OK, I fixed the case with release superbuilds using master. I'm not 100% sure of the best way to fix: Do: test --superbuild for a branch with backports. I'll think on it. --Ben From bob.obara at kitware.com Wed Oct 25 10:26:24 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 25 Oct 2017 10:26:24 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules Message-ID: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> Hi All, I?ve added the ability for an attribute definition to inherit the association rule from its base definition. This should streamline the creation of templates. For example you can create a definition called ?Surface Boundary Condition? and assign an association rule to indicate that it can be associated with faces. By default and definition based on ?Surface Boundary Condition? will inherit this association rule and therefore be associated with model faces. You can still override the inherited rule (note that in this implementation it will replace the entire rule). To support this functionality there were some changes made to the attribute::Definition API: associationRule() - returns the association rule that the definition uses - note that this can be a rule inherited from its Base Definition. As a result this method now returns a shared pointer to a const model entity item definition localAssociationRule() - returns the local association rule overriding the rule the definition would inherit from its base definition (Note that this can be nullptr) createLocalAssociationRule() - creates a local association rule for the definition (by default its associated with nothing) clearLocalAssociationRule() - removes the local association rule- the definition will now use the one inherited by its base definition setAssociationRule(...) -> setLocalAssociationRule(?) - sets the definition?s local association rule that overrides the one inherited by its base definition associationMask() -> returns the association mask that the definition uses - note that this can be the mask inherited from its Base Definition. setAssociationMask->setLocalAssociationMask - sets the mask of the local association rule (and creates one if necessary) What needs to be done in the future is to determine what constraints (if any) are imposed on the local association rule by the association rule inherited by the base definition? Does the rule need to be a subset or a superset of the inherited rule. For Example assume a base definition foo can be applied to edges and faces A definition bar is derived from foo and is going to have a local association rule Which of the following are allowed? 1. bar can be associated with just faces (its rule is a subset of foo?s rule) 2. bar can be associated with edges, faces, and volumes (its rule is a superset) 3. bar can be associated with volumes (its rule is independent) The question boils down to if bar can be treated as a foo then should it be associated to at least all things foo? - then the we do superset or is it a specialization of foo - in that case its a subset I think case 3 (independent) is probably not allowed? Note that the functionality is currently being tested and should be committed soon. Comments? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Oct 25 10:29:47 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 25 Oct 2017 10:29:47 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <20171025142410.GA29522@megas.kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> <20171025142410.GA29522@megas.kitware.com> Message-ID: Thanks Ben - will a: Do: test ?merged retest the merge request on both? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Oct 25, 2017, at 10:24 AMEDT, Ben Boeckel wrote: > > On Wed, Oct 25, 2017 at 09:44:28 -0400, Bob Obara wrote: >> I think there maybe an issue when testing merge requests w/r to >> release - can you checkout the experimental merge request builds for >> Inheriting association info on master and let me know if I?m doing >> something wrong? > > OK, I fixed the case with release superbuilds using master. I'm not 100% > sure of the best way to fix: > > Do: test --superbuild > > for a branch with backports. I'll think on it. > > --Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Oct 25 11:12:50 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Oct 2017 11:12:50 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> <20171025142410.GA29522@megas.kitware.com> Message-ID: <20171025151250.GA10296@megas.kitware.com> On Wed, Oct 25, 2017 at 10:29:47 -0400, Bob Obara wrote: > Thanks Ben - will a: Do: test ?merged retest the merge request on both? Yes, That will show up as a different build to buildbot (since the commits never existed before, buildbot can't say it has already done that). The release developer install still needs to be run yet. I've force-rebuilt the release superbuilds. --Ben From haocheng.liu at kitware.com Wed Oct 25 14:22:31 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 25 Oct 2017 14:22:31 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> Message-ID: Hi Bob, On Wed, Oct 25, 2017 at 10:26 AM, Bob Obara wrote: > Hi All, > > I?ve added the ability for an attribute definition to inherit the > association rule from its base definition. This should streamline the > creation of templates. > > For example you can create a definition called ?Surface Boundary > Condition? and assign an association rule to indicate that it can be > associated with faces. By default and definition based on ?Surface > Boundary Condition? will inherit this association rule and therefore be > associated with model faces. > You can still override the inherited rule (note that in this > implementation it will replace the entire rule). > > To support this functionality there were some changes made to the > attribute::Definition API: > > associationRule() - returns the association rule that the definition uses > - note that this can be a rule inherited from its Base Definition. As a > result this method now returns a shared pointer to a const model entity > item definition > localAssociationRule() - returns the local association rule overriding the > rule the definition would inherit from its base definition (Note that this > can be nullptr) > createLocalAssociationRule() - creates a local association rule for the > definition (by default its associated with nothing) > clearLocalAssociationRule() - removes the local association rule- the > definition will now use the one inherited by its base definition > setAssociationRule(...) -> setLocalAssociationRule(?) - sets the > definition?s local association rule that overrides the one inherited by its > base definition > associationMask() -> returns the association mask that the definition uses > - note that this can be the mask inherited from its Base Definition. > setAssociationMask->setLocalAssociationMask - sets the mask of the local > association rule (and creates one if necessary) > > What needs to be done in the future is to determine what constraints (if > any) are imposed on the local association rule by the association rule > inherited by the base definition? Does the rule need to be a subset or a > superset of the inherited rule. > > For Example assume a base definition foo can be applied to edges and faces > A definition bar is derived from foo and is going to have a local > association rule > > Which of the following are allowed? > > 1. bar can be associated with just faces (its rule is a subset of foo?s > rule) > 2. bar can be associated with edges, faces, and volumes (its rule is a > superset) > 3. bar can be associated with volumes (its rule is independent) > > The question boils down to if bar can be treated as a foo then should it > be associated to at least all things foo? - then the we do superset > or is it a specialization of foo - in that case its a subset > > I think case 3 (independent) is probably not allowed? > Just my 2 cents opinion, I think both case 2 and case 3 should not be allowed. Since bar is derived from foo, it should not go beyond foo. If case 2 happens, then the user should rethink about the definition of foo. Either he or her should expand foo to incude volumes or transform it into case 3 in which bar just happens to share the same Boundary condition with foo but they are independent of each other. > > Note that the functionality is currently being tested and should be > committed soon. > > > Comments? > > Bob > > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 <(518)%20881-4931> > > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/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 david.thompson at kitware.com Wed Oct 25 14:31:34 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 25 Oct 2017 14:31:34 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> Message-ID: <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> > ... > For Example assume a base definition foo can be applied to edges and faces > A definition bar is derived from foo and is going to have a local association rule > > Which of the following are allowed? > > 1. bar can be associated with just faces (its rule is a subset of foo?s rule) > 2. bar can be associated with edges, faces, and volumes (its rule is a superset) > 3. bar can be associated with volumes (its rule is independent) > > The question boils down to if bar can be treated as a foo then should it be associated to at least all things foo? - then the we do superset > or is it a specialization of foo - in that case its a subset > > I think case 3 (independent) is probably not allowed? I can think of a use case you may not like, but which I can imagine a user attempting: Imagine a solver that can handle both 2D and 3D simulations. User A has develops an attribute system for 2D simulations using the solver and contributes it to the community. Now user B takes user A's system and wants to inherit its definitions but change the model associations so it will work with 3D systems. That is case 3 (independent rules) because boundary conditions and materials need to be different dimensions in the 3D case. David From ben.boeckel at kitware.com Wed Oct 25 16:11:05 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 25 Oct 2017 16:11:05 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <20171025142410.GA29522@megas.kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> <20171025142410.GA29522@megas.kitware.com> Message-ID: <20171025201105.GA22074@megas.kitware.com> On Wed, Oct 25, 2017 at 10:24:10 -0400, Ben Boeckel wrote: > OK, I fixed the case with release superbuilds using master. I'm not 100% > sure of the best way to fix: > > Do: test --superbuild > > for a branch with backports. I'll think on it. Well, 4 more schedulers seem to have done the trick: release superbuild grabs a release cmb now. --Ben From bob.obara at kitware.com Wed Oct 25 17:06:43 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 25 Oct 2017 17:06:43 -0400 Subject: [Smtk-developers] The more complicated backport format In-Reply-To: <20171025201105.GA22074@megas.kitware.com> References: <6F7321A7-17A4-4D9F-96E7-74DCEE8B44EC@kitware.com> <20171025130411.GB5635@megas.kitware.com> <14F985B4-CF2F-409B-B2C6-0A8CB4A768DD@kitware.com> <20171025142410.GA29522@megas.kitware.com> <20171025201105.GA22074@megas.kitware.com> Message-ID: Great!, I?ll try retesting.... Bob Sent from my iPad > On Oct 25, 2017, at 4:11 PM, Ben Boeckel wrote: > >> On Wed, Oct 25, 2017 at 10:24:10 -0400, Ben Boeckel wrote: >> OK, I fixed the case with release superbuilds using master. I'm not 100% >> sure of the best way to fix: >> >> Do: test --superbuild >> >> for a branch with backports. I'll think on it. > > Well, 4 more schedulers seem to have done the trick: release superbuild > grabs a release cmb now. > > --Ben From bob.obara at kitware.com Wed Oct 25 17:33:37 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 25 Oct 2017 17:33:37 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> Message-ID: Hi Guys, Like Haocheng, I?m leaning towards the subset criteria. David, you bring up a good use case that I can see happening, through I don?t think independent rules will solve the problem in an elegant way. Let?s assume the 2d template was using rule inheritance so that all boundary conditions can be assigned to edges come from a common boundary condition definition. Similarly, all surface conditions are derived from a common definition that has a face association rule. Now, to reuse the template and change edges to faces and faces to volumes would require all of the leaf definitions to have a new definition derived from them to change the inherited association rule since you couldn?t simply change the base definition rules. It would certainly be doable but cumbersome. I would probably suggest that instead, the entire template get copied for the 3D case and physically change the base definition rules. One way to avoiding the copying of the template would be to somehow abstract out the topology information. Way back we had talked about having more abstract/conceptual model entity references like boundary and domain. Based on the dimension of the model, the interpretation of boundary and domain w/r actual topological elements would be determined. I?m not saying we should implement this approach but it would solve it the use case. Does that make sense? Sent from my iPad On Oct 25, 2017, at 2:31 PM, David Thompson wrote: >> ... >> For Example assume a base definition foo can be applied to edges and faces >> A definition bar is derived from foo and is going to have a local association rule >> >> Which of the following are allowed? >> >> 1. bar can be associated with just faces (its rule is a subset of foo?s rule) >> 2. bar can be associated with edges, faces, and volumes (its rule is a superset) >> 3. bar can be associated with volumes (its rule is independent) >> >> The question boils down to if bar can be treated as a foo then should it be associated to at least all things foo? - then the we do superset >> or is it a specialization of foo - in that case its a subset >> >> I think case 3 (independent) is probably not allowed? > > I can think of a use case you may not like, but which I can imagine a user attempting: > > Imagine a solver that can handle both 2D and 3D simulations. > User A has develops an attribute system for 2D simulations using the solver and contributes it to the community. > Now user B takes user A's system and wants to inherit its definitions but change the model associations so it will work with 3D systems. > That is case 3 (independent rules) because boundary conditions and materials need to be different dimensions in the 3D case. > > David From john.tourtellott at kitware.com Wed Oct 25 17:35:21 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Wed, 25 Oct 2017 17:35:21 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> Message-ID: Mostly FYI, with MR 925 , we will have case 3 (independent). So the associativity settings will be more like a default than an inheritance for now. On Wed, Oct 25, 2017 at 2:31 PM, David Thompson wrote: > > ... > > For Example assume a base definition foo can be applied to edges and > faces > > A definition bar is derived from foo and is going to have a local > association rule > > > > Which of the following are allowed? > > > > 1. bar can be associated with just faces (its rule is a subset of foo?s > rule) > > 2. bar can be associated with edges, faces, and volumes (its rule is a > superset) > > 3. bar can be associated with volumes (its rule is independent) > > > > The question boils down to if bar can be treated as a foo then should it > be associated to at least all things foo? - then the we do superset > > or is it a specialization of foo - in that case its a subset > > > > I think case 3 (independent) is probably not allowed? > > I can think of a use case you may not like, but which I can imagine a user > attempting: > > Imagine a solver that can handle both 2D and 3D simulations. > User A has develops an attribute system for 2D simulations using the > solver and contributes it to the community. > Now user B takes user A's system and wants to inherit its definitions but > change the model associations so it will work with 3D systems. > That is case 3 (independent rules) because boundary conditions and > materials need to be different dimensions in the 3D case. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Oct 25 17:46:29 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 25 Oct 2017 17:46:29 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> Message-ID: ... > Like Haocheng, I?m leaning towards the subset criteria. ... > Does that make sense? It feels a little arbitrary to me, but I don't have a problem with it. The operator examples which come to mind can be solved by injecting a new base class that is the entire set of all entity types the operator supports and subclassing that. David From haocheng.liu at kitware.com Wed Oct 25 17:51:57 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 25 Oct 2017 17:51:57 -0400 Subject: [Smtk-developers] New Feature for Attribute Definitions - inheritable association rules In-Reply-To: References: <147C57A8-A164-4C4E-A7FB-9BCEAD0B0D9D@kitware.com> <42D81EA7-02C8-415A-9169-6942617819C1@kitware.com> Message-ID: On Wed, Oct 25, 2017 at 5:46 PM, David Thompson wrote: > ... > > Like Haocheng, I?m leaning towards the subset criteria. ... > > Does that make sense? > > It feels a little arbitrary to me, but I don't have a problem with it. The > operator examples which come to mind can be solved by injecting a new base > class that is the entire set of all entity types the operator supports and > subclassing that. > +1. If it's a base boundary condition, it should cover all entity types and user could tailor the derived definition to meet their needs. > > 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 Thu Oct 26 11:23:59 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 26 Oct 2017 11:23:59 -0400 Subject: [Smtk-developers] SMTK In-Reply-To: <20171026132350.GA14911@megas.kitware.com> References: <59F93F88-8CDA-4EDF-AD37-5A61925A0F94@kitware.com> <20171026132350.GA14911@megas.kitware.com> Message-ID: <3987360D-2EB7-4AE3-A97A-ECF2406A1D90@kitware.com> >>> I am seeing the same problem moho is having here: >>> https://open.cdash.org/viewBuildError.php?buildid=5116245 >>> on my macos machine. Perhaps it is related to a recent PV change? I hope it is not something I did, but I don't see how. The first error (in vtkModuleAPI.cmake:131): >>> ... > > My guess: > https://gitlab.kitware.com/vtk/vtk/merge_requests/3451 Yes, that appears to be the source of the problem. However, VTK MR 3493 (the suggested fix in 3451's discussion) does not fix the problem for me. Even adding Brad's comment to fix things, I get the log below when running CMake on CMB+SMTK. Also, since 3493 hasn't even been merged to VTK yet, much less ParaView, should we revert the PV sha in the superbuild? David /Stage/Build/cmb/5 % cmake . -Wno-dev -- Boost version: 1.64.0 -- Found the following Boost libraries: -- date_time -- filesystem -- system -- Found PythonLibs: /usr/local/Frameworks/Python.framework/Python (found version "2.7.13") -- Boost version: 1.64.0 -- Found the following Boost libraries: -- thread -- filesystem -- system -- chrono -- date_time -- atomic -- Found PythonLibs: /usr/local/Frameworks/Python.framework/Python -- Performing Test VTK_UNDEFINED_SYMBOLS_ALLOWED - Failed CMake Error at ThirdParty/SMTK/CMake/smtkVTKModules.cmake:59 (add_subdirectory): The binary directory /Stage/Build/cmb/5/ThirdParty/SMTK/smtk/extension/opencv/vtk is already used to build a source directory. It cannot be used to build source directory /Stage/Source/cmb/5/ThirdParty/SMTK/smtk/extension/opencv/vtk Specify a unique binary directory name. Call Stack (most recent call first): ThirdParty/SMTK/smtk/extension/opencv/CMakeLists.txt:25 (vtk_smtk_process_modules) -- Performing Test VTK_UNDEFINED_SYMBOLS_ALLOWED - Failed -- CMAKE_CXX_COMPILER_ID='AppleClang' -- CMAKE_CXX_FLAGS='-Wall -Wextra -Wno-deprecated -Wno-inconsistent-missing-override' -- CMAKE_C_FLAGS='' -- Boost version: 1.64.0 -- Found the following Boost libraries: -- thread -- filesystem -- system -- date_time -- chrono -- atomic -- Found PythonInterp: /usr/local/bin/python2.7 (found version "2.7.13") -- Found PythonLibs: /usr/local/Frameworks/Python.framework/Python -- Configuring incomplete, errors occurred! See also "/Stage/Build/cmb/5/CMakeFiles/CMakeOutput.log". See also "/Stage/Build/cmb/5/CMakeFiles/CMakeError.log". From david.thompson at kitware.com Thu Oct 26 11:28:50 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 26 Oct 2017 11:28:50 -0400 Subject: [Smtk-developers] SMTK In-Reply-To: <3987360D-2EB7-4AE3-A97A-ECF2406A1D90@kitware.com> References: <59F93F88-8CDA-4EDF-AD37-5A61925A0F94@kitware.com> <20171026132350.GA14911@megas.kitware.com> <3987360D-2EB7-4AE3-A97A-ECF2406A1D90@kitware.com> Message-ID: >>>> I am seeing the same problem moho is having here: >>>> https://open.cdash.org/viewBuildError.php?buildid=5116245 >>>> on my macos machine. Perhaps it is related to a recent PV change? I hope it is not something I did, but I don't see how. The first error (in vtkModuleAPI.cmake:131): >>>> ... >> >> My guess: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/3451 > > Yes, that appears to be the source of the problem. However, VTK MR 3493 (the suggested fix in 3451's discussion) does not fix the problem for me. Even adding Brad's comment to fix things, I get the log below when running CMake on CMB+SMTK. Also, since 3493 hasn't even been merged to VTK yet, much less ParaView, should we revert the PV sha in the superbuild? Err... Sorry, VTK MR 3493 *does* fix things for me (I had made a local change to SMTK trying to debug things). I am OK waiting for this MR to make it into VTK, then PV, then the superbuilds. Or reverting for now. Either one. David From haocheng.liu at kitware.com Thu Oct 26 11:37:20 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 26 Oct 2017 11:37:20 -0400 Subject: [Smtk-developers] SMTK In-Reply-To: References: <59F93F88-8CDA-4EDF-AD37-5A61925A0F94@kitware.com> <20171026132350.GA14911@megas.kitware.com> <3987360D-2EB7-4AE3-A97A-ECF2406A1D90@kitware.com> Message-ID: On Thu, Oct 26, 2017 at 11:28 AM, David Thompson wrote: > >>>> I am seeing the same problem moho is having here: > >>>> https://open.cdash.org/viewBuildError.php?buildid=5116245 > >>>> on my macos machine. Perhaps it is related to a recent PV change? I > hope it is not something I did, but I don't see how. The first error (in > vtkModuleAPI.cmake:131): > >>>> ... > >> > >> My guess: > >> https://gitlab.kitware.com/vtk/vtk/merge_requests/3451 > > > > Yes, that appears to be the source of the problem. However, VTK MR 3493 > (the suggested fix in 3451's discussion) does not fix the problem for me. > Even adding Brad's comment to fix things, I get the log below when running > CMake on CMB+SMTK. Also, since 3493 hasn't even been merged to VTK yet, > much less ParaView, should we revert the PV sha in the superbuild? > > Err... Sorry, VTK MR 3493 *does* fix things for me (I had made a local > change to SMTK trying to debug things). > > I am OK waiting for this MR to make it into VTK, then PV, then the > superbuilds. Or reverting for now. Either one. > > I would vote for pushing things forward to make the change reach superbuild by the end of day. I would bug people around. > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/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 david.thompson at kitware.com Thu Oct 26 19:59:40 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 26 Oct 2017 19:59:40 -0400 Subject: [Smtk-developers] More build problems Message-ID: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> Hi all, Are any of you having CMB build problems related to wslink? cmake 3.9.4? wslink is a python-only library (nothing compiled), but ParaView is now including it as a dependency as if it needed CS wrapping, so when trying to build CMB_Plugin, I get: % ninja [2/170] Linking CXX shared library lib/cmb-5.0/libCMB_Plugin.dylib FAILED: lib/cmb-5.0/libCMB_Plugin.dylib : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -Wall -Wextra -Wno-deprecated -Wno-inconsistent-missing-override -g -arch x86_64 ... /Stage/Build/cmb/superbuild/superbuild/paraview/build/lib/libvtkPVServerManagerApplicationCS-pv5.4.a -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS ... ld: library not found for -lwslink If I manually remove "-lwslink[^ ]* " from build.ninja, the error changes to: Undefined symbols for architecture x86_64: "vtkCMBArcPolygonProvider::AddInnerLoopArcIds(vtkIdTypeArray*)", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "vtkCMBArcPolygonProvider::SetOuterLoopArcIds(vtkIdTypeArray*)", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "vtkCMBPolygonFromArcsOperator::GetInnerLoop(long long const&)", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "vtkCMBPolygonFromArcsOperator::GetOuterLoop()", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "vtkCMBPolygonFromArcsOperator::GetNumberOfInnerLoops()", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "vtkCMBPolygonFromArcsOperator::AddArcId(long long)", referenced from: vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o "_wslinkCS_Initialize", referenced from: _CMB_Plugin_CombinedInitialize in CMB_Plugin_Plugin.cxx.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. which I can almost fix by adding vtkCMBMeshing as a private dependency of CMB_Plugin (which appears to be a real problem, but why is it only showing up now?). I say almost, because that still leaves me with: vtkCMBArcPolygonCreateClientOperator.cxx.o "_wslinkCS_Initialize", referenced from: _CMB_Plugin_CombinedInitialize in CMB_Plugin_Plugin.cxx.o Note that CMB_Plugin_Plugin.cxx is a generated file. If I hand-edit that file to remove the wslink CS-initialization calls, then CMB_Plugin compiles and only one other dependency problem crops up (SceneBuilder apparently missing vtkCMBIO as a direct dependency). This is with cmake 3.9.4 on macos 10.13. I'll submit a MR for the SceneBuilder and CMB_Plugin dependencies that need fixing, but I'm at a loss about how to fix the wslink stuff. Any ideas? Confusedly, David From haocheng.liu at kitware.com Thu Oct 26 22:33:33 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 26 Oct 2017 22:33:33 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> Message-ID: <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> Hi David, I can try it tomorrow, but may i ask do I have to use cmake 3.9.4? Best rgrds Haocheng LIU > On Oct 26, 2017, at 7:59 PM, David Thompson wrote: > > Hi all, > > Are any of you having CMB build problems related to wslink? cmake 3.9.4? wslink is a python-only library (nothing compiled), but ParaView is now including it as a dependency as if it needed CS wrapping, so when trying to build CMB_Plugin, I get: > > % ninja > [2/170] Linking CXX shared library lib/cmb-5.0/libCMB_Plugin.dylib > FAILED: lib/cmb-5.0/libCMB_Plugin.dylib > : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -Wall -Wextra -Wno-deprecated -Wno-inconsistent-missing-override -g -arch x86_64 ... /Stage/Build/cmb/superbuild/superbuild/paraview/build/lib/libvtkPVServerManagerApplicationCS-pv5.4.a -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS -lwslink -lwslinkCS ... > > ld: library not found for -lwslink > > If I manually remove "-lwslink[^ ]* " from build.ninja, the error changes to: > > Undefined symbols for architecture x86_64: > "vtkCMBArcPolygonProvider::AddInnerLoopArcIds(vtkIdTypeArray*)", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "vtkCMBArcPolygonProvider::SetOuterLoopArcIds(vtkIdTypeArray*)", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "vtkCMBPolygonFromArcsOperator::GetInnerLoop(long long const&)", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "vtkCMBPolygonFromArcsOperator::GetOuterLoop()", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "vtkCMBPolygonFromArcsOperator::GetNumberOfInnerLoops()", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "vtkCMBPolygonFromArcsOperator::AddArcId(long long)", referenced from: > vtkCMBArcPolygonCreateClientOperator::Create(double, double, vtkSMProxy*) in vtkCMBArcPolygonCreateClientOperator.cxx.o > "_wslinkCS_Initialize", referenced from: > _CMB_Plugin_CombinedInitialize in CMB_Plugin_Plugin.cxx.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > ninja: build stopped: subcommand failed. > > which I can almost fix by adding vtkCMBMeshing as a private dependency of CMB_Plugin (which appears to be a real problem, but why is it only showing up now?). I say almost, because that still leaves me with: > > vtkCMBArcPolygonCreateClientOperator.cxx.o > "_wslinkCS_Initialize", referenced from: > _CMB_Plugin_CombinedInitialize in CMB_Plugin_Plugin.cxx.o > > Note that CMB_Plugin_Plugin.cxx is a generated file. If I hand-edit that file to remove the wslink CS-initialization calls, then CMB_Plugin compiles and only one other dependency problem crops up (SceneBuilder apparently missing vtkCMBIO as a direct dependency). > > This is with cmake 3.9.4 on macos 10.13. > > I'll submit a MR for the SceneBuilder and CMB_Plugin dependencies that need fixing, but I'm at a loss about how to fix the wslink stuff. Any ideas? > > Confusedly, > David From david.thompson at kitware.com Thu Oct 26 22:41:50 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 26 Oct 2017 22:41:50 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> Message-ID: <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> > I can try it tomorrow, but may i ask do I have to use cmake 3.9.4? I downgraded to cmake 3.9.2 (what I was using before all of the problems) and still have the wslink issue. So: no, you should not have to use 3.9.4. David From ben.boeckel at kitware.com Fri Oct 27 08:50:40 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 27 Oct 2017 08:50:40 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> Message-ID: <20171027125040.GA14204@megas.kitware.com> On Thu, Oct 26, 2017 at 19:59:40 -0400, David Thompson wrote: > Are any of you having CMB build problems related to wslink? cmake > 3.9.4? wslink is a python-only library (nothing compiled), but > ParaView is now including it as a dependency as if it needed CS > wrapping, so when trying to build CMB_Plugin, I get: I wonder if it's not being detected as a Python library at all. Could you get a --trace-expand from the configure step? That can help figure out where it gets into a link line. --Ben From haocheng.liu at kitware.com Fri Oct 27 08:55:32 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 27 Oct 2017 08:55:32 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: On Thu, Oct 26, 2017 at 10:41 PM, David Thompson wrote: > > I can try it tomorrow, but may i ask do I have to use cmake 3.9.4? > > I downgraded to cmake 3.9.2 (what I was using before all of the problems) > and still have the wslink issue. So: no, you should not have to use 3.9.4. > > I just kicked off a brand-new cmb superbuild. I suppose that's enough to expose the problem right, David? > 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 Fri Oct 27 10:07:31 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 27 Oct 2017 10:07:31 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: <20171027125040.GA14204@megas.kitware.com> References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <20171027125040.GA14204@megas.kitware.com> Message-ID: Hi Ben, >> Are any of you having CMB build problems related to wslink? ... > > I wonder if it's not being detected as a Python library at all. Could > you get a --trace-expand from the configure step? That can help figure > out where it gets into a link line. I am running it now, but so far it is 195 MB and grep reports 339 matching lines. David From david.thompson at kitware.com Fri Oct 27 10:08:30 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 27 Oct 2017 10:08:30 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: Hi Haocheng, > ... >> I downgraded to cmake 3.9.2 (what I was using before all of the problems) and still have the wslink issue. So: no, you should not have to use 3.9.4. >> > I just kicked off a brand-new cmb superbuild. I suppose that's enough to expose the problem right, David? I would think. David From haocheng.liu at kitware.com Fri Oct 27 10:19:41 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 27 Oct 2017 10:19:41 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: On Fri, Oct 27, 2017 at 10:08 AM, David Thompson wrote: > Hi Haocheng, > > > ... > >> I downgraded to cmake 3.9.2 (what I was using before all of the > problems) and still have the wslink issue. So: no, you should not have to > use 3.9.4. > >> > > I just kicked off a brand-new cmb superbuild. I suppose that's enough to > expose the problem right, David? > > I would think. > > David > > It builds successfully on my Ubuntu 16.04 + GCC 5.4 + CMake 3.9.0. -- 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 bob.obara at kitware.com Fri Oct 27 13:08:54 2017 From: bob.obara at kitware.com (Bob Obara) Date: Fri, 27 Oct 2017 13:08:54 -0400 Subject: [Smtk-developers] Upgrading Mac Testing Machines Message-ID: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> Hi All, The current testing infrastructure is: Trenzalore - 10.12.x Sierra (2016) TalosIV - 10.11.x El Capitan (2015) Junction 10.10.x Yosemite (2014) I?m thinking of moving everyone up one version so that Tranzalore would be running High Sierra (10.13.x) - Any comments? Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Oct 27 13:40:36 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 27 Oct 2017 13:40:36 -0400 Subject: [Smtk-developers] [Cmb-users] Upgrading Mac Testing Machines In-Reply-To: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> References: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> Message-ID: <829A09AB-F7CB-4714-9A9C-6C699CF7C9E2@kitware.com> > The current testing infrastructure is: > > Trenzalore - 10.12.x Sierra (2016) > TalosIV - 10.11.x El Capitan (2015) > Junction 10.10.x Yosemite (2014) > > I?m thinking of moving everyone up one version so that Tranzalore would be running High Sierra (10.13.x) - Any comments? +1 From david.thompson at kitware.com Fri Oct 27 13:43:02 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 27 Oct 2017 13:43:02 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: Wiping and rebuilding got things working, although this uses the PV sha in the superbuild which is not what I had been building with (which was master PV + VTK, including JC's fixes). David From haocheng.liu at kitware.com Fri Oct 27 14:16:17 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 27 Oct 2017 14:16:17 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: Using Cory's MR as ParaView SHA does not solve the problem... I would info JC. On Fri, Oct 27, 2017 at 1:43 PM, David Thompson wrote: > Wiping and rebuilding got things working, although this uses the PV sha in > the superbuild which is not what I had been building with (which was master > PV + VTK, including JC's fixes). > > 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 tj.corona at kitware.com Fri Oct 27 14:17:43 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 27 Oct 2017 14:17:43 -0400 Subject: [Smtk-developers] [Cmb-users] Upgrading Mac Testing Machines In-Reply-To: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> References: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> Message-ID: <5DC31841-BA55-489F-9DBE-31662E8770CF@kitware.com> Sounds like a good plan! Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On Oct 27, 2017, at 1:08 PM, Bob Obara wrote: > > Hi All, > > The current testing infrastructure is: > > Trenzalore - 10.12.x Sierra (2016) > TalosIV - 10.11.x El Capitan (2015) > Junction 10.10.x Yosemite (2014) > > I?m thinking of moving everyone up one version so that Tranzalore would be running High Sierra (10.13.x) - Any comments? > > Bob > > Robert M. O'Bara, MEng. > Assistant Director of Scientific Computing > > Kitware Inc. > 28 Corporate Drive > Suite 101 > Clifton Park, NY 12065 > > Phone: (518) 881- 4931 > > > > > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Fri Oct 27 14:23:58 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 27 Oct 2017 14:23:58 -0400 Subject: [Smtk-developers] More build problems In-Reply-To: References: <05C28A64-7E92-4F5C-A5A5-2E60351886DD@kitware.com> <0E5F3F84-734B-434E-B220-A306121FA732@kitware.com> <1F50768E-56E5-452C-81AD-701C5B5DEDEE@kitware.com> Message-ID: Here is the discussion link . On Fri, Oct 27, 2017 at 2:16 PM, Haocheng Liu wrote: > Using Cory's MR > as > ParaView SHA does not solve the problem... I would info JC. > > On Fri, Oct 27, 2017 at 1:43 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Wiping and rebuilding got things working, although this uses the PV sha >> in the superbuild which is not what I had been building with (which was >> master PV + VTK, including JC's fixes). >> >> 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> > -- 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 bob.obara at kitware.com Fri Oct 27 14:44:09 2017 From: bob.obara at kitware.com (Bob Obara) Date: Fri, 27 Oct 2017 14:44:09 -0400 Subject: [Smtk-developers] [Cmb-users] Upgrading Mac Testing Machines In-Reply-To: <5DC31841-BA55-489F-9DBE-31662E8770CF@kitware.com> References: <1C25322A-BD1A-4184-8D55-BA60F96B1D8A@kitware.com> <5DC31841-BA55-489F-9DBE-31662E8770CF@kitware.com> Message-ID: <053E9E2C-A906-46E5-8DDD-06D7B2889DA0@kitware.com> Slight change of plans :) Its seems that apple has made it difficult to find the 10.12 installation so I?m going to keep Trenzalore where it is and instead upgrade TalosIV to High Sierra. Let me know if you have any issues with this :) Bob Robert M. O'Bara, MEng. Assistant Director of Scientific Computing Kitware Inc. 28 Corporate Drive Suite 101 Clifton Park, NY 12065 Phone: (518) 881- 4931 > On Oct 27, 2017, at 2:17 PMEDT, TJ Corona wrote: > > Sounds like a good plan! > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 > >> On Oct 27, 2017, at 1:08 PM, Bob Obara > wrote: >> >> Hi All, >> >> The current testing infrastructure is: >> >> Trenzalore - 10.12.x Sierra (2016) >> TalosIV - 10.11.x El Capitan (2015) >> Junction 10.10.x Yosemite (2014) >> >> I?m thinking of moving everyone up one version so that Tranzalore would be running High Sierra (10.13.x) - Any comments? >> >> Bob >> >> Robert M. O'Bara, MEng. >> Assistant Director of Scientific Computing >> >> Kitware Inc. >> 28 Corporate Drive >> Suite 101 >> Clifton Park, NY 12065 >> >> Phone: (518) 881- 4931 >> >> >> >> >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: