From david.thompson at kitware.com Wed Jun 1 14:54:49 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 14:54:49 -0400 Subject: [Smtk-developers] SMTK build error Message-ID: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> Hi all, It appears shiboken is failing because recent commits have left a '#include "boost/..."' statement unguarded. Shiboken cannot parse most boost headers (any that include the preprocessor package for sure). I should have a MR to fix things shortly. David From yumin.yuan at kitware.com Wed Jun 1 15:23:02 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Wed, 1 Jun 2016 15:23:02 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> Message-ID: Thanks, David. I also did a bit debugging in shiboken, and it turns out it failed to parse one of boost headers (line 31 of static_assert.hpp) # define BOOST_STATIC_ASSERT_MSG( ... ) static_assert(__VA_ARGS__) The commit is f4eba409, " SharedPtr now also detects support of make_shared" Yumin On Wed, Jun 1, 2016 at 2:54 PM, David Thompson wrote: > Hi all, > > It appears shiboken is failing because recent commits have left a > '#include "boost/..."' statement unguarded. Shiboken cannot parse most > boost headers (any that include the preprocessor package for sure). I > should have a MR to fix things shortly. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Jun 1 15:26:14 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 15:26:14 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> Message-ID: <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> > I also did a bit debugging in shiboken, and it turns out it failed to parse one of boost headers (line 31 of static_assert.hpp) > > # define BOOST_STATIC_ASSERT_MSG( ... ) static_assert(__VA_ARGS__) > > The commit is f4eba409, " SharedPtr now also detects support of make_shared" Yes, it looks like that causes breakage (at least on Mac OS X: newer clang compilers cannot determine the template type and one isn't provided) in shared pointer detection, which then falls back to boost -- and those headers are not guarded against wrapping. I'm testing and will have a patch this afternoon. David From robert.maynard at kitware.com Wed Jun 1 16:50:55 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Jun 2016 16:50:55 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> Message-ID: Can you open an issue that provides / points me towards how the newer clang compilers are failing the c++11 check for shared ptr? That is something that should work going forward. On Wed, Jun 1, 2016 at 3:26 PM, David Thompson wrote: >> I also did a bit debugging in shiboken, and it turns out it failed to parse one of boost headers (line 31 of static_assert.hpp) >> >> # define BOOST_STATIC_ASSERT_MSG( ... ) static_assert(__VA_ARGS__) >> >> The commit is f4eba409, " SharedPtr now also detects support of make_shared" > > Yes, it looks like that causes breakage (at least on Mac OS X: newer clang compilers cannot determine the template type and one isn't provided) in shared pointer detection, which then falls back to boost -- and those headers are not guarded against wrapping. I'm testing and will have a patch this afternoon. > > David From david.thompson at kitware.com Wed Jun 1 17:04:59 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 17:04:59 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> Message-ID: <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> > Can you open an issue that provides / points me towards how the newer > clang compilers are failing the c++11 check for shared ptr? > > That is something that should work going forward. Here's the error message: Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' std::shared_ptr f = std::make_shared(42.0f); ^~~~~~~~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' make_shared(_Args&& ...__args) ^ 1 error generated. ninja: build stopped: subcommand failed. If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) David From robert.maynard at kitware.com Wed Jun 1 17:19:30 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Jun 2016 17:19:30 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> Message-ID: I will do one better. Here is the MR that fixes the issue ( that I created ): https://gitlab.kitware.com/cmb/smtk/merge_requests/95 On Wed, Jun 1, 2016 at 5:04 PM, David Thompson wrote: >> Can you open an issue that provides / points me towards how the newer >> clang compilers are failing the c++11 check for shared ptr? >> >> That is something that should work going forward. > > > Here's the error message: > > Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" > [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o > FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx > /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' > std::shared_ptr f = std::make_shared(42.0f); > ^~~~~~~~~~~~~~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' > make_shared(_Args&& ...__args) > ^ > 1 error generated. > ninja: build stopped: subcommand failed. > > If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) > > David From david.thompson at kitware.com Wed Jun 1 17:34:06 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 17:34:06 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> Message-ID: <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> > Here is the MR that fixes the issue ( that I created ): > https://gitlab.kitware.com/cmb/smtk/merge_requests/95 Umm... I submitted a similar MR here: https://gitlab.kitware.com/cmb/smtk/merge_requests/94 that also fixes things in the event that boost shared pointers are used. The issue I don't want to deal with is figuring out how to avoid explicitly specifying the template parameter... Sorry, David > > On Wed, Jun 1, 2016 at 5:04 PM, David Thompson > wrote: >>> Can you open an issue that provides / points me towards how the newer >>> clang compilers are failing the c++11 check for shared ptr? >>> >>> That is something that should work going forward. >> >> >> Here's the error message: >> >> Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp >> >> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" >> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o >> FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx >> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' >> std::shared_ptr f = std::make_shared(42.0f); >> ^~~~~~~~~~~~~~~~ >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' >> make_shared(_Args&& ...__args) >> ^ >> 1 error generated. >> ninja: build stopped: subcommand failed. >> >> If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) >> >> David From robert.maynard at kitware.com Wed Jun 1 17:41:05 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Jun 2016 17:41:05 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> Message-ID: The shared_ptr test never compiling is orthogonal to the shiboken issue so that is why I broke it out into a separate MR. On Wed, Jun 1, 2016 at 5:34 PM, David Thompson wrote: >> Here is the MR that fixes the issue ( that I created ): >> https://gitlab.kitware.com/cmb/smtk/merge_requests/95 > > Umm... I submitted a similar MR here: > > https://gitlab.kitware.com/cmb/smtk/merge_requests/94 > > that also fixes things in the event that boost shared pointers are used. The issue I don't want to deal with is figuring out how to avoid explicitly specifying the template parameter... > > Sorry, > David > >> >> On Wed, Jun 1, 2016 at 5:04 PM, David Thompson >> wrote: >>>> Can you open an issue that provides / points me towards how the newer >>>> clang compilers are failing the c++11 check for shared ptr? >>>> >>>> That is something that should work going forward. >>> >>> >>> Here's the error message: >>> >>> Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp >>> >>> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" >>> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o >>> FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx >>> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' >>> std::shared_ptr f = std::make_shared(42.0f); >>> ^~~~~~~~~~~~~~~~ >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' >>> make_shared(_Args&& ...__args) >>> ^ >>> 1 error generated. >>> ninja: build stopped: subcommand failed. >>> >>> If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) >>> >>> David > From david.thompson at kitware.com Wed Jun 1 17:45:51 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 17:45:51 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> Message-ID: <539FF468-2095-4836-A4D3-670A1B12D265@kitware.com> Hi Rob, > The shared_ptr test never compiling is orthogonal to the shiboken > issue so that is why I broke it out into a separate MR. But we cannot merge both of them because MR 94 addresses both. It is a tiny fix and I would rather not spend more time on it. Do you really think it's important to rewrite MR 94? David > > On Wed, Jun 1, 2016 at 5:34 PM, David Thompson > wrote: >>> Here is the MR that fixes the issue ( that I created ): >>> https://gitlab.kitware.com/cmb/smtk/merge_requests/95 >> >> Umm... I submitted a similar MR here: >> >> https://gitlab.kitware.com/cmb/smtk/merge_requests/94 >> >> that also fixes things in the event that boost shared pointers are used. The issue I don't want to deal with is figuring out how to avoid explicitly specifying the template parameter... >> >> Sorry, >> David >> >>> >>> On Wed, Jun 1, 2016 at 5:04 PM, David Thompson >>> wrote: >>>>> Can you open an issue that provides / points me towards how the newer >>>>> clang compilers are failing the c++11 check for shared ptr? >>>>> >>>>> That is something that should work going forward. >>>> >>>> >>>> Here's the error message: >>>> >>>> Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp >>>> >>>> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" >>>> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o >>>> FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx >>>> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' >>>> std::shared_ptr f = std::make_shared(42.0f); >>>> ^~~~~~~~~~~~~~~~ >>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' >>>> make_shared(_Args&& ...__args) >>>> ^ >>>> 1 error generated. >>>> ninja: build stopped: subcommand failed. >>>> >>>> If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) >>>> >>>> David >> From robert.maynard at kitware.com Wed Jun 1 17:47:54 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Jun 2016 17:47:54 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: <539FF468-2095-4836-A4D3-670A1B12D265@kitware.com> References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> <539FF468-2095-4836-A4D3-670A1B12D265@kitware.com> Message-ID: MR closed. On Wed, Jun 1, 2016 at 5:45 PM, David Thompson wrote: > Hi Rob, > >> The shared_ptr test never compiling is orthogonal to the shiboken >> issue so that is why I broke it out into a separate MR. > > But we cannot merge both of them because MR 94 addresses both. It is a tiny fix and I would rather not spend more time on it. Do you really think it's important to rewrite MR 94? > > David > >> >> On Wed, Jun 1, 2016 at 5:34 PM, David Thompson >> wrote: >>>> Here is the MR that fixes the issue ( that I created ): >>>> https://gitlab.kitware.com/cmb/smtk/merge_requests/95 >>> >>> Umm... I submitted a similar MR here: >>> >>> https://gitlab.kitware.com/cmb/smtk/merge_requests/94 >>> >>> that also fixes things in the event that boost shared pointers are used. The issue I don't want to deal with is figuring out how to avoid explicitly specifying the template parameter... >>> >>> Sorry, >>> David >>> >>>> >>>> On Wed, Jun 1, 2016 at 5:04 PM, David Thompson >>>> wrote: >>>>>> Can you open an issue that provides / points me towards how the newer >>>>>> clang compilers are failing the c++11 check for shared ptr? >>>>>> >>>>>> That is something that should work going forward. >>>>> >>>>> >>>>> Here's the error message: >>>>> >>>>> Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp >>>>> >>>>> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" >>>>> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o >>>>> FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx >>>>> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' >>>>> std::shared_ptr f = std::make_shared(42.0f); >>>>> ^~~~~~~~~~~~~~~~ >>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' >>>>> make_shared(_Args&& ...__args) >>>>> ^ >>>>> 1 error generated. >>>>> ninja: build stopped: subcommand failed. >>>>> >>>>> If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) >>>>> >>>>> David >>> > From david.thompson at kitware.com Wed Jun 1 18:35:08 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 1 Jun 2016 18:35:08 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> <539FF468-2095-4836-A4D3-670A1B12D265@kitware.com> Message-ID: > MR closed. Thanks, Rob. David > > On Wed, Jun 1, 2016 at 5:45 PM, David Thompson > wrote: >> Hi Rob, >> >>> The shared_ptr test never compiling is orthogonal to the shiboken >>> issue so that is why I broke it out into a separate MR. >> >> But we cannot merge both of them because MR 94 addresses both. It is a tiny fix and I would rather not spend more time on it. Do you really think it's important to rewrite MR 94? >> >> David >> >>> >>> On Wed, Jun 1, 2016 at 5:34 PM, David Thompson >>> wrote: >>>>> Here is the MR that fixes the issue ( that I created ): >>>>> https://gitlab.kitware.com/cmb/smtk/merge_requests/95 >>>> >>>> Umm... I submitted a similar MR here: >>>> >>>> https://gitlab.kitware.com/cmb/smtk/merge_requests/94 >>>> >>>> that also fixes things in the event that boost shared pointers are used. The issue I don't want to deal with is figuring out how to avoid explicitly specifying the template parameter... >>>> >>>> Sorry, >>>> David >>>> >>>>> >>>>> On Wed, Jun 1, 2016 at 5:04 PM, David Thompson >>>>> wrote: >>>>>>> Can you open an issue that provides / points me towards how the newer >>>>>>> clang compilers are failing the c++11 check for shared ptr? >>>>>>> >>>>>>> That is something that should work going forward. >>>>>> >>>>>> >>>>>> Here's the error message: >>>>>> >>>>>> Trying shared ptr; result: Change Dir: /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp >>>>>> >>>>>> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" >>>>>> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o >>>>>> FAILED: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++11 -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx >>>>>> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no matching function for call to 'make_shared' >>>>>> std::shared_ptr f = std::make_shared(42.0f); >>>>>> ^~~~~~~~~~~~~~~~ >>>>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: note: candidate template ignored: couldn't infer template argument '_Tp' >>>>>> make_shared(_Args&& ...__args) >>>>>> ^ >>>>>> 1 error generated. >>>>>> ninja: build stopped: subcommand failed. >>>>>> >>>>>> If you really think it's worth an issue, feel free to open one but please don't assign it to me. :-) >>>>>> >>>>>> David >>>> >> From yumin.yuan at kitware.com Thu Jun 2 09:29:32 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 2 Jun 2016 09:29:32 -0400 Subject: [Smtk-developers] SMTK build error In-Reply-To: References: <7465C113-8FFB-480F-97A6-6F5BAF5B6171@kitware.com> <69AB1A91-4312-4DDF-8CC2-2DD0C03179D4@kitware.com> <353C8530-F1D7-4F01-B3D6-F47843EC6D43@kitware.com> <08BEE642-D2FD-4A0C-BE76-AEAAE2A9B92A@kitware.com> <539FF468-2095-4836-A4D3-670A1B12D265@kitware.com> Message-ID: David, I did +1 to your MR, but you have to be the one merging it. Yumin On Wed, Jun 1, 2016 at 6:35 PM, David Thompson wrote: > > MR closed. > > Thanks, Rob. > > David > > > > > On Wed, Jun 1, 2016 at 5:45 PM, David Thompson > > wrote: > >> Hi Rob, > >> > >>> The shared_ptr test never compiling is orthogonal to the shiboken > >>> issue so that is why I broke it out into a separate MR. > >> > >> But we cannot merge both of them because MR 94 addresses both. It is a > tiny fix and I would rather not spend more time on it. Do you really think > it's important to rewrite MR 94? > >> > >> David > >> > >>> > >>> On Wed, Jun 1, 2016 at 5:34 PM, David Thompson > >>> wrote: > >>>>> Here is the MR that fixes the issue ( that I created ): > >>>>> https://gitlab.kitware.com/cmb/smtk/merge_requests/95 > >>>> > >>>> Umm... I submitted a similar MR here: > >>>> > >>>> https://gitlab.kitware.com/cmb/smtk/merge_requests/94 > >>>> > >>>> that also fixes things in the event that boost shared pointers are > used. The issue I don't want to deal with is figuring out how to avoid > explicitly specifying the template parameter... > >>>> > >>>> Sorry, > >>>> David > >>>> > >>>>> > >>>>> On Wed, Jun 1, 2016 at 5:04 PM, David Thompson > >>>>> wrote: > >>>>>>> Can you open an issue that provides / points me towards how the > newer > >>>>>>> clang compilers are failing the c++11 check for shared ptr? > >>>>>>> > >>>>>>> That is something that should work going forward. > >>>>>> > >>>>>> > >>>>>> Here's the error message: > >>>>>> > >>>>>> Trying shared ptr; result: Change Dir: > /Stage/Build/SMTK/polygon/CMakeTmp/CMakeFiles/CMakeTmp > >>>>>> > >>>>>> Run Build Command:"/usr/local/bin/ninja" "cmTC_e0daa" > >>>>>> [1/2] Building CXX object CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o > >>>>>> FAILED: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ > -std=c++11 -arch x86_64 -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk > -mmacosx-version-min=10.10 -o CMakeFiles/cmTC_e0daa.dir/shared_ptr.cxx.o -c > /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx > >>>>>> /Stage/Source/SMTK/polygon/CMake/shared_ptr.cxx:14:30: error: no > matching function for call to 'make_shared' > >>>>>> std::shared_ptr f = std::make_shared(42.0f); > >>>>>> ^~~~~~~~~~~~~~~~ > >>>>>> > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4747:1: > note: candidate template ignored: couldn't infer template argument '_Tp' > >>>>>> make_shared(_Args&& ...__args) > >>>>>> ^ > >>>>>> 1 error generated. > >>>>>> ninja: build stopped: subcommand failed. > >>>>>> > >>>>>> If you really think it's worth an issue, feel free to open one but > please don't assign it to me. :-) > >>>>>> > >>>>>> David > >>>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jun 17 13:52:49 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 17 Jun 2016 13:52:49 -0400 Subject: [Smtk-developers] Operator visibility Message-ID: <914F7BDE-296B-479F-9688-3103D7B04C82@kitware.com> Hi Bob, We had discussed operators indicating whether they should be hidden by default or not. How would you model this in the attribute system? Here are a few ideas I had: 1. Is it possible for attributes (the operators) to change the default of an inherited item? 2. The presence of an item with a particular name (like "hidden") indicates invisibility? 3. Internal operator definitions could inherit from "hidden operator" (which in turn would inherit the base "operator" attribute definition. I think 3 sounds like the best unless #1 is possible. David From bob.obara at kitware.com Sun Jun 19 11:20:20 2016 From: bob.obara at kitware.com (Bob Obara) Date: Sun, 19 Jun 2016 11:20:20 -0400 Subject: [Smtk-developers] Using C++ 11 Syntax Message-ID: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> Hi All, I would like to start using some parts of C++ 11 - for example using auto. Do feel that this is ok? I noticed that when I used auto I got a warning from building on the Mac. 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 Sun Jun 19 14:42:47 2016 From: david.thompson at kitware.com (David Thompson) Date: Sun, 19 Jun 2016 14:42:47 -0400 Subject: [Smtk-developers] Using C++ 11 Syntax In-Reply-To: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> References: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> Message-ID: <3F4ED8D0-BB09-4129-A64C-215506024EBA@kitware.com> Hi Bob, > I would like to start using some parts of C++ 11 - for example using auto. Do feel that this is ok? I noticed that when I used auto I got a warning from building on the Mac. I am fine with requiring C++11. In fact, Rob has opened a bug on the polygon session as it uses one bit that some compilers complain about (see [bug 13]() for details). I was planning to just disable the polygon session for older compilers rather than require C++11, but if you want to require C++11, I prefer that -- assuming all the platforms have at least one compiler that supports all the language features we use. David [bug 13]: https://gitlab.kitware.com/cmb/smtk/issues/13 From ben.boeckel at kitware.com Mon Jun 20 10:09:52 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 20 Jun 2016 10:09:52 -0400 Subject: [Smtk-developers] Using C++ 11 Syntax In-Reply-To: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> References: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> Message-ID: <20160620140952.GA21536@megas.kitware.com> On Sun, Jun 19, 2016 at 11:20:20 -0400, Bob Obara wrote: > I would like to start using some parts of C++ 11 - for example using > auto. Do feel that this is ok? I noticed that when I used auto I got > a warning from building on the Mac. Note that `endor` is probably the compiler with the weakest C++11 support (GCC 4.8.4) and is building for Ubuntu 14.04. When adding C++11 stuff, make sure it is supported there (or we can update the compiler/OS). --Ben From robert.maynard at kitware.com Tue Jun 21 08:29:09 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Jun 2016 08:29:09 -0400 Subject: [Smtk-developers] Using C++ 11 Syntax In-Reply-To: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> References: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> Message-ID: Mac-clang by default compiles in a warn-but-allow-c++11 mode currently, which means we need to explicitly state that we want to compile smtk with c++11. To keep the build logic simpler I agree with ben that we need to make sure our dashboards are all using compilers that support the set of C++11 features we desire. A quick search shows that GCC 4.8.X does support most of C++11 language features ( including auto ), but has problems with standard library features. On Sun, Jun 19, 2016 at 11:20 AM, Bob Obara wrote: > Hi All, > > I would like to start using some parts of C++ 11 - for example using auto. > Do feel that this is ok? I noticed that when I used auto I got a warning > from building on the Mac. > > 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 > From marcus.hanwell at kitware.com Tue Jun 21 11:10:18 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 21 Jun 2016 11:10:18 -0400 Subject: [Smtk-developers] Using C++ 11 Syntax In-Reply-To: References: <0A8742D9-DC2D-459D-A550-5493325425EB@kitware.com> Message-ID: http://doc.qt.io/qt-5/supported-platforms.html may be of interest, as Qt 5.7 requires C++11 their supported platforms for 5.7 is likely a good starting point. I was checking minimum OS versions for Qt yesterday and saw this. On Tue, Jun 21, 2016 at 8:29 AM, Robert Maynard wrote: > Mac-clang by default compiles in a warn-but-allow-c++11 mode > currently, which means we need to explicitly state that we want to > compile smtk with c++11. > > To keep the build logic simpler I agree with ben that we need to make > sure our dashboards are all using compilers that support the set of > C++11 features > we desire. A quick search shows that GCC 4.8.X does support most of > C++11 language features ( including auto ), but has problems with > standard library features. > > On Sun, Jun 19, 2016 at 11:20 AM, Bob Obara wrote: >> Hi All, >> >> I would like to start using some parts of C++ 11 - for example using auto. >> Do feel that this is ok? I noticed that when I used auto I got a warning >> from building on the Mac. >> >> 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 >> > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From bob.obara at kitware.com Tue Jun 28 22:48:25 2016 From: bob.obara at kitware.com (Bob Obara) Date: Tue, 28 Jun 2016 22:48:25 -0400 Subject: [Smtk-developers] Testing Data Message-ID: Hi All, I?ve created a possible new organization for testing data - checkout my new-organization branch in my CMB Testing Data Repo Let me know what you think. 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 Jun 29 08:10:40 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 08:10:40 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: References: Message-ID: <20160629121040.GC5811@megas.kitware.com> On Tue, Jun 28, 2016 at 22:48:25 -0400, Bob Obara wrote: > I?ve created a possible new organization for testing data - checkout > my new-organization branch in my CMB Testing Data Repo Link for the lazy :) : https://gitlab.kitware.com/bob.obara/cmb-testing-data/tree/new-organization --Ben From robert.maynard at kitware.com Wed Jun 29 09:08:39 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 29 Jun 2016 09:08:39 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: <20160629121040.GC5811@megas.kitware.com> References: <20160629121040.GC5811@megas.kitware.com> Message-ID: Thanks for the link ben! Thoughts: - Can we have consistent capitalization and plurality between the baseline folders ( CMB-Applications/Baseline && SMTK/baselines) - Plurality in general. I would prefer non plural forms for all directories ( Scene over Scenes / GeoTiff over GeoTiffs ) - MapFiles, PolyFiles, and SimulationFiles should have the Files section dropped - Looks like we are missing a STL folder, and a shallow water folder ( AdHShallowWater.simb.xml / AdHShallowWater.sbt ) Overall I like the layout, we just need to apply some polish. On Wed, Jun 29, 2016 at 8:10 AM, Ben Boeckel wrote: > On Tue, Jun 28, 2016 at 22:48:25 -0400, Bob Obara wrote: >> I?ve created a possible new organization for testing data - checkout >> my new-organization branch in my CMB Testing Data Repo > > Link for the lazy :) : > > https://gitlab.kitware.com/bob.obara/cmb-testing-data/tree/new-organization > > --Ben > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users From ben.boeckel at kitware.com Wed Jun 29 09:18:17 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 09:18:17 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: References: <20160629121040.GC5811@megas.kitware.com> Message-ID: <20160629131817.GE17842@megas.kitware.com> On Wed, Jun 29, 2016 at 09:08:39 -0400, Robert Maynard wrote: > - Can we have consistent capitalization and plurality between the > baseline folders ( CMB-Applications/Baseline && SMTK/baselines) FWIW, I'd prefer all-lowercase. --Ben From bob.obara at kitware.com Wed Jun 29 10:02:41 2016 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 29 Jun 2016 10:02:41 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: <20160629131817.GE17842@megas.kitware.com> References: <20160629121040.GC5811@megas.kitware.com> <20160629131817.GE17842@megas.kitware.com> Message-ID: <392DC321-F6EE-4641-9132-51B52FFEEB91@kitware.com> So Combining Ben and Rob?s comments we would have something like: cmb-application or cmb_application (in this case we could probably ditch the cmb part and just call it application - I?m just using this as an example style guide) - I?m leaning towards _ over -; Other comments: Missing stl directory - will add. There are a bunch of things in the top level directory that I?m not sure where they belong (or if they are just duplicates): AdHShallowWater.* cmb-testing-data.marker simpleadh.dat Also - There is a Simulations directory that look tests (for ModelBuilder?) Should it be moved under attribute? Perhaps the stuff under attribute/test should be attribute/test/smtk and the stuff in Simulations be renamed attribute/test/application ? Let me know what you think! 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 Jun 29, 2016, at 9:18 AMEDT, Ben Boeckel wrote: > > On Wed, Jun 29, 2016 at 09:08:39 -0400, Robert Maynard wrote: >> - Can we have consistent capitalization and plurality between the >> baseline folders ( CMB-Applications/Baseline && SMTK/baselines) > > FWIW, I'd prefer all-lowercase. > > --Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Wed Jun 29 10:04:45 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Wed, 29 Jun 2016 10:04:45 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: <20160629131817.GE17842@megas.kitware.com> References: <20160629121040.GC5811@megas.kitware.com> <20160629131817.GE17842@megas.kitware.com> Message-ID: Comments: 1. I would change CMB-applications/Baseline and SMTK/baselines to baselines/cmbapplications baselines/smtk 2. Agreeing with Rob, it will be good to also create directories for files (ADHShallowWater.sbt, simple.stl, etc) under root level 3. SimBuilderGUI folder has FunctionExpressions.py and FunctionExpressions.sbt file, which is used by a test that's added in V3 with this commit a726d2c31d679bb2da62979e2e1dd52be66521df and disabled in cmb V4 with commit due to missing test data directory 959cf16ee5927f8ece7b9563e8476c0ab95d7f77 I will take a look at it to see if this test is still relevant. Yumin On Wed, Jun 29, 2016 at 9:18 AM, Ben Boeckel wrote: > On Wed, Jun 29, 2016 at 09:08:39 -0400, Robert Maynard wrote: > > - Can we have consistent capitalization and plurality between the > > baseline folders ( CMB-Applications/Baseline && SMTK/baselines) > > FWIW, I'd prefer all-lowercase. > > --Ben > _______________________________________________ > 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 Jun 29 10:18:21 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Jun 2016 10:18:21 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: References: Message-ID: Hi all, > I?ve created a possible new organization for testing data - checkout my new-organization branch in my CMB Testing Data Repo > > Let me know what you think. 1. Thanks for switching to lowercase names. 2. Can we split solidModels into step, occ, iges, sat (if we have any), etc.? 3. I would argue the models in solidModels/problemModels should not be classified by whether they currently give us trouble or not... just by file type. Other classification information could go into a ReadMe (which we should probably put in each directory as we add files -- at a minimum to say where they came from). 4. The CMB files in MeshToModelMapping should move into filetype directories. 5. I would argue that directory names should not include "Files" (e.g., SimulationFiles => simulation, PolyFiles => poly, MapFiles => map, ...). 6. I agree with Yumin: there should be only a ReadMe and subdirectories at the top of the repo. My 2 cents, David From john.tourtellott at kitware.com Wed Jun 29 10:22:50 2016 From: john.tourtellott at kitware.com (John Tourtellott) Date: Wed, 29 Jun 2016 10:22:50 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: <20160629131817.GE17842@megas.kitware.com> References: <20160629121040.GC5811@megas.kitware.com> <20160629131817.GE17842@megas.kitware.com> Message-ID: I was thinking of more hierarchy, maybe, for example Data BoreholeGeography GeoTiffs LIDAR MapFiles PointClouds PolyFiles Meshes 2D 3D Exodus Models CMBModels 2D 3D MeshToModelMapping SolidModels Scenes Also - - Let's find a home for all of the individual files at the top level, even if its an "etc" folder - SimBuilderGUI should go somewhere else, maybe in CMB ModelBuilder/Testing On Wed, Jun 29, 2016 at 9:18 AM, Ben Boeckel wrote: > On Wed, Jun 29, 2016 at 09:08:39 -0400, Robert Maynard wrote: > > - Can we have consistent capitalization and plurality between the > > baseline folders ( CMB-Applications/Baseline && SMTK/baselines) > > FWIW, I'd prefer all-lowercase. > > --Ben > _______________________________________________ > 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 Jun 29 10:32:47 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Jun 2016 10:32:47 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: References: <20160629121040.GC5811@megas.kitware.com> <20160629131817.GE17842@megas.kitware.com> Message-ID: <54700FA8-6E33-4749-A476-E1D80E9C000A@kitware.com> Hi John, > I was thinking of more hierarchy, maybe, for example > > Data > ... > Meshes > ... > Models > ... > Scenes Since there are files that could serve multiple purposes (a mesh can be a model, some models are meshes, a scene will eventually be a model, etc.) I don't see us being able to keep this organized. The only thing that seems unambiguous to me is the format that the file is stored in. However, I agree that the toplevel could include an additional level: data occ poly shape geotiff ... baselines smtk applications ... workflows (submodule @SHA) ReadMe.md David From ben.boeckel at kitware.com Wed Jun 29 11:30:39 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 29 Jun 2016 11:30:39 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: References: Message-ID: <20160629153039.GC4279@megas.kitware.com> On Wed, Jun 29, 2016 at 10:18:21 -0400, David Thompson wrote: > 6. I agree with Yumin: there should be only a ReadMe and > subdirectories at the top of the repo. Do we have a license for this data? Creative Commons? --Ben From david.thompson at kitware.com Wed Jun 29 12:36:09 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 29 Jun 2016 12:36:09 -0400 Subject: [Smtk-developers] [Cmb-users] Testing Data In-Reply-To: <20160629153039.GC4279@megas.kitware.com> References: <20160629153039.GC4279@megas.kitware.com> Message-ID: <0C9DCD39-101B-438A-9819-F4E0CAB0BAF7@kitware.com> > >> 6. I agree with Yumin: there should be only a ReadMe and >> subdirectories at the top of the repo. > > Do we have a license for this data? Creative Commons? I doubt they are all under the same license as they are from many sources. That is why I suggested a ReadMe per directory. + The poly files like pmdc.poly are LGPL: https://people.sc.fsu.edu/~jburkardt/data/poly_3d/poly_3d.html + Some of the BRep (OpenCascade), IGES, and STEP models (the ones I added) are from CGM and licensed as it is (LGPL). I don't know about all of the others in solidModels. + The disk_out_ref.ex2 Exodus model is from Sandia and included in ParaView's test data. Whatever license there applies. + The pillbox netCDF model is from SLAC but is also distributed with ParaView (to test its SLAC reader). David