From tj.corona at kitware.com Wed Aug 2 11:29:27 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 2 Aug 2017 10:29:27 -0500 Subject: [Smtk-developers] A familiar error Message-ID: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> Hi all, There is something wrong with the OS X package for the ES superbuild. When run from the terminal, the following error message is produced: This application failed to start because it could not find or load the Qt platform plugin "cocoa" in ?". I know we?ve run into this before. What is the fix? 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 Wed Aug 2 11:40:48 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 2 Aug 2017 11:40:48 -0400 Subject: [Smtk-developers] A familiar error In-Reply-To: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> References: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> Message-ID: <20170802154048.GA28619@megas.kitware.com> On Wed, Aug 02, 2017 at 10:29:27 -0500, TJ Corona wrote: > There is something wrong with the OS X package for the ES superbuild. When run from the terminal, the following error message is produced: > > This application failed to start because it could not find or load the Qt platform plugin "cocoa" > in ?". > > I know we?ve run into this before. What is the fix? Oh, CMB is missing this code: https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/projects/paraview.bundle.common.cmake#L161 (There's code which uses `qt5_plugin_paths` in each platform-specific bundle script.) --Ben From john.tourtellott at kitware.com Wed Aug 2 13:52:11 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Wed, 2 Aug 2017 13:52:11 -0400 Subject: [Smtk-developers] A familiar error In-Reply-To: <20170802154048.GA28619@megas.kitware.com> References: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> <20170802154048.GA28619@megas.kitware.com> Message-ID: I'll also need to add this to databrowser. But just to be clear: - I presume this logic needs to be added to *all* bundle scripts? - And if so, would it make sense to put this in a (new) file in the cmake/ folder? On Wed, Aug 2, 2017 at 11:40 AM, Ben Boeckel wrote: > On Wed, Aug 02, 2017 at 10:29:27 -0500, TJ Corona wrote: > > There is something wrong with the OS X package for the ES superbuild. > When run from the terminal, the following error message is produced: > > > > This application failed to start because it could not find or load the > Qt platform plugin "cocoa" > > in ?". > > > > I know we?ve run into this before. What is the fix? > > Oh, CMB is missing this code: > > https://gitlab.kitware.com/paraview/paraview-superbuild/ > blob/master/projects/paraview.bundle.common.cmake#L161 > > (There's code which uses `qt5_plugin_paths` in each platform-specific > bundle script.) > > --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 john.tourtellott at kitware.com Wed Aug 2 18:12:06 2017 From: john.tourtellott at kitware.com (John Tourtellott) Date: Wed, 2 Aug 2017 18:12:06 -0400 Subject: [Smtk-developers] A familiar error In-Reply-To: References: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> <20170802154048.GA28619@megas.kitware.com> Message-ID: Follow-up question: do we need to do anything for *developer* builds with Qt5? I suspect not, but I am getting a non-fatal QXcbConnection error when closing some dialogs, and I see that libqxcb.so is one of the "install/plaforms" libs. QXcbConnection: XCB error: 3 (BadWindow), sequence: 4506, resource id: 7700468, major code: 40 (TranslateCoords), minor code: 0 On Wed, Aug 2, 2017 at 1:52 PM, John Tourtellott < john.tourtellott at kitware.com> wrote: > I'll also need to add this to databrowser. But just to be clear: > > - I presume this logic needs to be added to *all* bundle scripts? > - And if so, would it make sense to put this in a (new) file in the > cmake/ folder? > > > On Wed, Aug 2, 2017 at 11:40 AM, Ben Boeckel > wrote: > >> On Wed, Aug 02, 2017 at 10:29:27 -0500, TJ Corona wrote: >> > There is something wrong with the OS X package for the ES superbuild. >> When run from the terminal, the following error message is produced: >> > >> > This application failed to start because it could not find or load the >> Qt platform plugin "cocoa" >> > in ?". >> > >> > I know we?ve run into this before. What is the fix? >> >> Oh, CMB is missing this code: >> >> https://gitlab.kitware.com/paraview/paraview-superbuild/blob >> /master/projects/paraview.bundle.common.cmake#L161 >> >> (There's code which uses `qt5_plugin_paths` in each platform-specific >> bundle script.) >> >> --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 ben.boeckel at kitware.com Thu Aug 3 10:22:08 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 3 Aug 2017 10:22:08 -0400 Subject: [Smtk-developers] A familiar error In-Reply-To: References: <7A5D6851-BD53-4C0A-9A85-CAA08737E1C3@kitware.com> <20170802154048.GA28619@megas.kitware.com> Message-ID: <20170803142208.GA31760@megas.kitware.com> On Wed, Aug 02, 2017 at 18:12:06 -0400, John Tourtellott wrote: > Follow-up question: do we need to do anything for *developer* builds with > Qt5? I suspect not, but I am getting a non-fatal QXcbConnection error when > closing some dialogs, and I see that libqxcb.so is one of the > "install/plaforms" libs. No; that set is only used when making packages. Qt should be building all of your platform libraries. Do you see a libqxcb.so in the developer install? > QXcbConnection: XCB error: 3 (BadWindow), sequence: 4506, resource id: > 7700468, major code: 40 (TranslateCoords), minor code: 0 This could be an X problem too. Though I see at least one project has decided to just suppress it: https://github.com/GNS3/gns3-gui/commit/116cf557581b20c4d8fd76dbcf9598a6f3853ce2 It also looks like it could be an application error (trying to use the dialog after it has closed?): https://github.com/i3/i3/issues/2540 --Ben From tj.corona at kitware.com Tue Aug 8 12:29:25 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 8 Aug 2017 12:29:25 -0400 Subject: [Smtk-developers] Moving pybind11 out of SMTK Message-ID: <884E2F43-9A39-4EA5-A567-9B480E674A03@kitware.com> Hi all, This morning, we moved pybind11 out of SMTK and into the superbuild as a dependency. Until the superbuild updates on our dashboards, there will be some breakage if you rebase off of smtk master. Since the developer install on these machines won?t be replaced until the master successfully cycles, any merge requests that do not include the most recent merge should still build successfully, so this shouldn?t affect the testing of your merge requests. 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 tj.corona at kitware.com Wed Aug 9 15:59:07 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 9 Aug 2017 15:59:07 -0400 Subject: [Smtk-developers] Cannot package qt5 + CMB on OS X Message-ID: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> Hi all, I ran into this issue last week, and figured that I had borked my version of CMB. I then ran into this issue yesterday, and figured I had a bad Qt5. I have now run this with vanilla CMB + binary installed Qt5 and I get the same error when trying to package: 319: RuntimeError: Unable to find the 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from 319: /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder Is anyone else hitting this issue? Does anyone know a workaround? Sincerely, T.J. P.S. In order to get CMB to build, I had to comment out vtkTerrainExtraction stuff because it cannot find rtvl correctly. Has anyone seen this too? 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 tj.corona at kitware.com Wed Aug 9 16:14:31 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 9 Aug 2017 16:14:31 -0400 Subject: [Smtk-developers] Cannot package qt5 + CMB on OS X In-Reply-To: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> References: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> Message-ID: <8C3EC01F-7FB4-4680-8EAF-38DB6D9CDAAB@kitware.com> Perhaps a larger trace would be helpful: 319: WARNING: dependency from /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder to @rpath/QtConcurrent.framework/Versions/5/QtConcurrent requires a search path 319: CMake Error at /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/cpack/modelbuilder/DragNDrop/build/cmake_install.cmake:43 (message): 319: Failed to install ModelBuilder.app: 319: 319: Traceback (most recent call last): 319: 319: File "/Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/fixup_bundle.apple.py", line 630, in 319: main(sys.argv[1:]) 319: File "/Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/fixup_bundle.apple.py", line 616, in main 319: _install_binary(main_exe, is_excluded, bundle_dest, installed, manifest, dry_run=opts.dry_run) 319: File "/Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/fixup_bundle.apple.py", line 491, in _install_binary 319: deps = binary.dependencies.values() 319: File "/Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/fixup_bundle.apple.py", line 225, in dependencies 319: deplib = Library.create_from_reference(dep, self) 319: File "/Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/fixup_bundle.apple.py", line 262, in create_from_reference 319: raise RuntimeError('Unable to find the %s library from %s' % (ref, loader.path)) 319: 319: RuntimeError: Unable to find the 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from 319: /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder 319: 319: 319: 319: 319: CPack Error: Error when generating package: CMB 319: CMake Error at /Users/tjcorona/Development/Software/cmb/superbuild_scratch/source/superbuild/cmake/scripts/package_test.cmake:21 (message): 319: CPack failed with exit code 1 319: 319: Last week I ran into something similar with the Capstone session: >> dependency from /Volumes/Samsung_250_EC/cmb-superbuild/build/install/lib/libsmtkCapstoneSession_Plugin.dylib to @rpath/QtWidgets.framework/Versions/5/QtWidgets requires a search path >> 316: searching for @rpath/QtWidgets.framework/Versions/5/QtWidgets > > This means that the capstone session library is using @rpath, but not > setting an rpath. Either don't use it or add an rpath. > > ?Ben That made more sense, though, because the Capsone session does explicitly use rpaths. I thought that ModelBuilder shouldn?t use rpaths though. 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 > On Aug 9, 2017, at 3:59 PM, TJ Corona wrote: > > Hi all, > > I ran into this issue last week, and figured that I had borked my version of CMB. I then ran into this issue yesterday, and figured I had a bad Qt5. I have now run this with vanilla CMB + binary installed Qt5 and I get the same error when trying to package: > > 319: RuntimeError: Unable to find the > 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from > 319: /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder > > Is anyone else hitting this issue? Does anyone know a workaround? > > Sincerely, > T.J. > > P.S. In order to get CMB to build, I had to comment out vtkTerrainExtraction stuff because it cannot find rtvl correctly. Has anyone seen this too? > > 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 haocheng.liu at kitware.com Wed Aug 9 16:31:39 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 9 Aug 2017 16:31:39 -0400 Subject: [Smtk-developers] Cannot package qt5 + CMB on OS X In-Reply-To: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> References: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> Message-ID: On Wed, Aug 9, 2017 at 3:59 PM, TJ Corona wrote: > Hi all, > > I ran into this issue last week, and figured that I had borked my version > of CMB. I then ran into this issue yesterday, and figured I had a bad Qt5. > I have now run this with vanilla CMB + binary installed Qt5 and I get the > same error when trying to package: > > 319: RuntimeError: Unable to find the > 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from > 319: /Users/tjcorona/Development/Software/cmb/superbuild_ > scratch/build/install/Applications/ModelBuilder.app/ > Contents/MacOS/ModelBuilder > > Is anyone else hitting this issue? Does anyone know a workaround? > > Sincerely, > T.J. > > P.S. In order to get CMB to build, I had to comment out > vtkTerrainExtraction stuff because it cannot find rtvl correctly. Has > anyone seen this too? > Proudly to say that it' been fix now! Using SMTK master + CMB master should be fine. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 <(518)%20881-4443> > > > _______________________________________________ > 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 tj.corona at kitware.com Wed Aug 9 18:30:02 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 9 Aug 2017 18:30:02 -0400 Subject: [Smtk-developers] Cannot package qt5 + CMB on OS X In-Reply-To: References: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> Message-ID: Thanks Haocheng! With the updated CMB I tried building with a homebrew-installed qt5, and everything built correctly. When packaging, though, I have the exact same error message as before. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On Aug 9, 2017, at 4:31 PM, Haocheng Liu wrote: > > > > On Wed, Aug 9, 2017 at 3:59 PM, TJ Corona > wrote: > Hi all, > > I ran into this issue last week, and figured that I had borked my version of CMB. I then ran into this issue yesterday, and figured I had a bad Qt5. I have now run this with vanilla CMB + binary installed Qt5 and I get the same error when trying to package: > > 319: RuntimeError: Unable to find the > 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from > 319: /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder > > Is anyone else hitting this issue? Does anyone know a workaround? > > Sincerely, > T.J. > > P.S. In order to get CMB to build, I had to comment out vtkTerrainExtraction stuff because it cannot find rtvl correctly. Has anyone seen this too? > Proudly to say that it' been fix now! Using SMTK master + CMB master should be fine. > > 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 > > > > > -- > 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 ben.boeckel at kitware.com Thu Aug 10 09:18:17 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Aug 2017 09:18:17 -0400 Subject: [Smtk-developers] Cannot package qt5 + CMB on OS X In-Reply-To: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> References: <8DFA5896-8538-4EDB-88CB-76B52E5B3ADC@kitware.com> Message-ID: <20170810131817.GA7579@megas.kitware.com> On Wed, Aug 09, 2017 at 15:59:07 -0400, TJ Corona wrote: > I ran into this issue last week, and figured that I had borked my > version of CMB. I then ran into this issue yesterday, and figured I > had a bad Qt5. I have now run this with vanilla CMB + binary installed > Qt5 and I get the same error when trying to package: > > 319: RuntimeError: Unable to find the > 319: @rpath/QtConcurrent.framework/Versions/5/QtConcurrent library from > 319: /Users/tjcorona/Development/Software/cmb/superbuild_scratch/build/install/Applications/ModelBuilder.app/Contents/MacOS/ModelBuilder > > Is anyone else hitting this issue? Does anyone know a workaround? Your Qt is using @rpath, but nothing is saying what to add to the rpath list. It's a known problem on macOS across the board. CMake should probably handle this stuff itself, but it's not a simple fix. --Ben From bob.obara at kitware.com Wed Aug 16 08:51:37 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 16 Aug 2017 08:51:37 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types Message-ID: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Hi All, I?ve started modifying the existing Resource class and have a question as to how SMTK should return the Resource?s Type (model, mesh, attribute, etc..) - The class currently uses an enum which is fast and does enforce uniformity but will require new types of resources to modify the base class to add new enum (like VTK) . We also could just return a string which would be more flexible but is a bit slower to compare. The same question pertains to the type of ResourceComponents. 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 haocheng.liu at kitware.com Wed Aug 16 09:02:26 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 16 Aug 2017 09:02:26 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: Hi Bob, On Wed, Aug 16, 2017 at 8:51 AM, Robert Michael O'Bara < bob.obara at kitware.com> wrote: > Hi All, > > I?ve started modifying the existing Resource class and have a question as > to how SMTK should return the Resource?s Type (model, mesh, attribute, > etc..) - The class currently uses an enum which is fast and does enforce > uniformity but will require new types of resources to modify the base > class to add new enum (like VTK) . We also could just return a string > which would be more flexible but is a bit slower to compare. > > Personally I prefer enum since it's less error-prone. Also model, mesh, attribute and etc are foundations of SMTK so it's not likely we would change them frequently. The same question pertains to the type of ResourceComponents. > > 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 <(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 Aug 16 09:18:25 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 16 Aug 2017 09:18:25 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: > I?ve started modifying the existing Resource class and have a question as to how SMTK should return the Resource?s Type (model, mesh, attribute, etc..) - The class currently uses an enum which is fast and does enforce uniformity but will require new types of resources to modify the base class to add new enum (like VTK) . We also could just return a string which would be more flexible but is a bit slower to compare. At the resource level, strings seem to make a lot more sense because it doesn't feel like we've finished the list of resource types yet (candidates might be: simulation, job, view, workflow template). > The same question pertains to the type of ResourceComponents. Can we use dynamic casting of the parent resource or some other formalism to avoid the string comparison at the component level? That way things in tight loops would be fast but we would still be flexible. I worry that if we start with an enum and then add cases all the pre-existing switch statements would add fragility; people seem to deal with strings a little more defensively than enums. David From haocheng.liu at kitware.com Wed Aug 16 09:29:19 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 16 Aug 2017 09:29:19 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: Hi David, On Wed, Aug 16, 2017 at 9:18 AM, David Thompson wrote: > > I?ve started modifying the existing Resource class and have a question > as to how SMTK should return the Resource?s Type (model, mesh, attribute, > etc..) - The class currently uses an enum which is fast and does enforce > uniformity but will require new types of resources to modify the base > class to add new enum (like VTK) . We also could just return a string > which would be more flexible but is a bit slower to compare. > > At the resource level, strings seem to make a lot more sense because it > doesn't feel like we've finished the list of resource types yet (candidates > might be: simulation, job, view, workflow template). > > > The same question pertains to the type of ResourceComponents. > > Can we use dynamic casting of the parent resource or some other formalism > to avoid the string comparison at the component level? That way things in > tight loops would be fast but we would still be flexible. I worry that if > we start with an enum and then add cases all the pre-existing switch > statements would add fragility; people seem to deal with strings a little > more defensively than enums. > > How about using C++11 strong type enum? I've already started using them in smtk for the past months. It's type-safe, fast and flexible. > 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 bob.obara at kitware.com Wed Aug 16 17:48:00 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 16 Aug 2017 17:48:00 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: My main question concerning ResourceComponent::type is should it be a superset of all the model entity types along with Attribute, Attribute Definition, Mesh Field, Mesh PointSet, Mesh Cell Set? This would mean needing to conform to SMTK Models? bit encoded pattern. I think for now we could just use a enum class for Resource::Type. 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 Aug 16, 2017, at 9:29 AMEDT, Haocheng Liu wrote: > > Hi David, > > On Wed, Aug 16, 2017 at 9:18 AM, David Thompson > wrote: > > I?ve started modifying the existing Resource class and have a question as to how SMTK should return the Resource?s Type (model, mesh, attribute, etc..) - The class currently uses an enum which is fast and does enforce uniformity but will require new types of resources to modify the base class to add new enum (like VTK) . We also could just return a string which would be more flexible but is a bit slower to compare. > > At the resource level, strings seem to make a lot more sense because it doesn't feel like we've finished the list of resource types yet (candidates might be: simulation, job, view, workflow template). > > > The same question pertains to the type of ResourceComponents. > > Can we use dynamic casting of the parent resource or some other formalism to avoid the string comparison at the component level? That way things in tight loops would be fast but we would still be flexible. I worry that if we start with an enum and then add cases all the pre-existing switch statements would add fragility; people seem to deal with strings a little more defensively than enums. > > How about using C++11 strong type enum? I've already started using them in smtk for the past months. It's type-safe, fast and flexible. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Wed Aug 16 18:18:26 2017 From: bob.obara at kitware.com (Bob Obara) Date: Wed, 16 Aug 2017 18:18:26 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: <3442B145-E193-43C2-85B7-3477942E4A55@kitware.com> We discussed having Attribute Definitions also be a Resource Component (like Attribute). After some thought I think this is not a good idea for the following reasons: Definitions would have a UUID assigned to them as well. The complication this introduces is that currently all attribute template files are written by hand and would not initially have one Technically an attribute template is for the creating of a new attribute system so what would it mean for definitions to a a UUID that is the same for different attribute systems. 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 > On Aug 16, 2017, at 5:48 PMEDT, Bob Obara wrote: > > My main question concerning ResourceComponent::type is should it be a superset of all the model entity types along with Attribute, Attribute Definition, Mesh Field, Mesh PointSet, Mesh Cell Set? This would mean needing to conform to SMTK Models? bit encoded pattern. > > I think for now we could just use a enum class for Resource::Type. > > 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 Aug 16, 2017, at 9:29 AMEDT, Haocheng Liu > wrote: >> >> Hi David, >> >> On Wed, Aug 16, 2017 at 9:18 AM, David Thompson > wrote: >> > I?ve started modifying the existing Resource class and have a question as to how SMTK should return the Resource?s Type (model, mesh, attribute, etc..) - The class currently uses an enum which is fast and does enforce uniformity but will require new types of resources to modify the base class to add new enum (like VTK) . We also could just return a string which would be more flexible but is a bit slower to compare. >> >> At the resource level, strings seem to make a lot more sense because it doesn't feel like we've finished the list of resource types yet (candidates might be: simulation, job, view, workflow template). >> >> > The same question pertains to the type of ResourceComponents. >> >> Can we use dynamic casting of the parent resource or some other formalism to avoid the string comparison at the component level? That way things in tight loops would be fast but we would still be flexible. I worry that if we start with an enum and then add cases all the pre-existing switch statements would add fragility; people seem to deal with strings a little more defensively than enums. >> >> How about using C++11 strong type enum? I've already started using them in smtk for the past months. It's type-safe, fast and flexible. >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Aug 17 08:51:11 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Aug 2017 08:51:11 -0400 Subject: [Smtk-developers] Resource and ResourceComponent Types In-Reply-To: References: <1DE89369-9E98-435D-9B29-549C418C9391@kitware.com> Message-ID: <20170817125111.GC18506@megas.kitware.com> On Wed, Aug 16, 2017 at 09:18:25 -0400, David Thompson wrote: > flexible. I worry that if we start with an enum and then add cases all > the pre-existing switch statements would add fragility; people seem to > deal with strings a little more defensively than enums. Enums can have warnings associated with them when all cases aren't handled so that you at least know that you missed a variant. Strings can't have that. I don't see how enums have fragility where strings don't. --Ben From bob.obara at kitware.com Mon Aug 21 15:02:04 2017 From: bob.obara at kitware.com (Bob Obara) Date: Mon, 21 Aug 2017 15:02:04 -0400 Subject: [Smtk-developers] Resource Changes Message-ID: Hi All, This weekend I changed the Resource class and added the ResourceComponent class: class SMTKCORE_EXPORT Resource : smtkEnableSharedPtr(Resource) { friend class ResourceManager; public: smtkTypeMacro(Resource); virtual ~Resource(); std::string location() const; ResourceManager *manager() const const UUID& id() const; // Would like to get rid of the following but ResourceSet needs them /// Identifies resource type enum Type { ATTRIBUTE = 0, MODEL, MESH, // future NUMBER_OF_TYPES }; virtual Resource::Type resourceType() const = 0; virtual ResourceComponentPtr find(const UUID& compId) const = 0; static std::string type2String(Resource::Type t); static Resource::Type string2Type(const std::string& s); protected: Resource(const UUID &myID, ResourceManager *manager); Resource(ResourceManager *manager); void setId(const UUID &myID); void setLocation(const std::string &url); private: UUID m_id; std::string m_url; ResourceManager *m_manager; }; class SMTKCORE_EXPORT ResourceComponent : smtkEnableSharedPtr(ResourceComponent) { friend class Resource; public: smtkTypeMacro(ResourceComponent); virtual ~ResourceComponent(); virtual ResourcePtr resource() const = 0; const UUID& id() const {return this->m_id;} protected: ResourceComponent(const UUID &myID); ResourceComponent(); void setId(const UUID &myID) {this->m_id = myID;} private: UUID m_id; }; Now there are two classes that are related to Resources : common/ResourceSet and model/StoredResource. Its ResourceSet that seems to be used the Resource::Type information and StoredResource seems to be tracking stored Model Resources. What I think needs to be done is: ResourceSet ?> Project or ResourceManager StoredResource ?> Resource (meaning we need to move some of its functionality over to Resource) StoreResource has the following API: class SMTKCORE_EXPORT StoredResource : public smtk::common::Resource { public: smtkTypeMacro(StoredResource); smtkCreateMacro(StoredResource); smtkSharedFromThisMacro(smtk::common::Resource); virtual ~StoredResource(); std::string url() const; bool setURL(const std::string& url, bool isModified = false); void markModified(bool isDirty = true); bool isModified() const; int generation() const; bool exists(const std::string& prefix = "") const; Resource::Type resourceType() const override { return MODEL; } smtk::common::ResourceComponentPtr find(const smtk::common::UUID& compId) const override; bool addEntity(const EntityRef& ent); bool removeEntity(const EntityRef& ent); const EntityRefs& entities() const { return this->m_entities; } SessionRef session() const; size_t addURLDisposition(const URLDisposition& disposition); const std::vector& dispositions() const { return this->m_dispositions; } bool clearDispositions(); protected: StoredResource(); void setGeneration(int gen); std::string m_url; // The location where this resource is stored. int m_generation; // The generation number the last time an entity in the resource was modified. int m_urlGeneration; // The generation number at the last time the resource was written to/read from disk. EntityRefs m_entities; // The model entities stored by this resource. std::vector m_dispositions; // Used to plan a write operation; only valid during writes. }; The url method is already in Resource (its called location) isModified() and markModified(..) seem to make sense generation() - is this like modifiedTime()? Should it be a posix date-time and should it be set when the Resource is saved? No Clue as to what Dispositions are and why we need them. 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 Aug 23 17:06:56 2017 From: tj.corona at kitware.com (TJ Corona) Date: Wed, 23 Aug 2017 17:06:56 -0400 Subject: [Smtk-developers] rtvl in SMTK Message-ID: Hi all, As a developer on a Mac, I?ve always gotten these annoying messages about rt(v/g)l and symbol visibility mismatching. It used to be in CMB, but with the recent move of the terrain extraction code to SMTK, it now shows up whenever I try to build SMTK. Untended warnings lead to more warnings and broken dashboards, so I spoke with Ben to figure out how to approach this issue. One possible fix we came up with is to update the superbuild?s VXL to the latest version, use the rtvl from within vxl and fix up vxl?s symbol export logic to do the right thing (apparently the latest master has much of this done, but it has not been propagated to rt(v/g)l). What do you guys think? 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 Wed Aug 23 17:13:14 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 23 Aug 2017 17:13:14 -0400 Subject: [Smtk-developers] rtvl in SMTK In-Reply-To: References: Message-ID: <20170823211314.GB32462@megas.kitware.com> On Wed, Aug 23, 2017 at 17:06:56 -0400, TJ Corona wrote: > As a developer on a Mac, I?ve always gotten these annoying messages > about rt(v/g)l and symbol visibility mismatching. It used to be in > CMB, but with the recent move of the terrain extraction code to SMTK, > it now shows up whenever I try to build SMTK. Untended warnings lead > to more warnings and broken dashboards, so I spoke with Ben to figure > out how to approach this issue. One possible fix we came up with is to > update the superbuild?s VXL to the latest version, use the rtvl from > within vxl and fix up vxl?s symbol export logic to do the right thing > (apparently the latest master has much of this done, but it has not > been propagated to rt(v/g)l). What do you guys think? Note that the commit of VXL we're using correlates with this branch: https://github.com/judajake/vxl/tree/cmb_vxl --Ben From haocheng.liu at kitware.com Wed Aug 23 17:19:40 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 23 Aug 2017 17:19:40 -0400 Subject: [Smtk-developers] rtvl in SMTK In-Reply-To: <20170823211314.GB32462@megas.kitware.com> References: <20170823211314.GB32462@megas.kitware.com> Message-ID: On Wed, Aug 23, 2017 at 5:13 PM, Ben Boeckel wrote: > On Wed, Aug 23, 2017 at 17:06:56 -0400, TJ Corona wrote: > > As a developer on a Mac, I?ve always gotten these annoying messages > > about rt(v/g)l and symbol visibility mismatching. It used to be in > > CMB, but with the recent move of the terrain extraction code to SMTK, > > it now shows up whenever I try to build SMTK. Untended warnings lead > > to more warnings and broken dashboards, so I spoke with Ben to figure > > out how to approach this issue. One possible fix we came up with is to > > update the superbuild?s VXL to the latest version, use the rtvl from > > within vxl and fix up vxl?s symbol export logic to do the right thing > > (apparently the latest master has much of this done, but it has not > > been propagated to rt(v/g)l). What do you guys think? > > +1 for updating VXL to the latest version. > Note that the commit of VXL we're using correlates with this branch: > > https://github.com/judajake/vxl/tree/cmb_vxl > > --Ben > _______________________________________________ > 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 Aug 24 09:18:56 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 24 Aug 2017 09:18:56 -0400 Subject: [Smtk-developers] rtvl in SMTK In-Reply-To: References: Message-ID: Hi TJ, > As a developer on a Mac, I?ve always gotten these annoying messages about rt(v/g)l and symbol visibility mismatching. ... One possible fix we came up with is to update the superbuild?s VXL to the latest version, use the rtvl from within vxl and fix up vxl?s symbol export logic to do the right thing (apparently the latest master has much of this done, but it has not been propagated to rt(v/g)l). What do you guys think? Looking at the link Ben sent to the branch we're on, I see "This branch is 3 commits ahead, 2148 commits behind vxl:master." +1, but not if similar to kicking a dead whale down the beach. David