From bob.obara at kitware.com Thu Jan 21 23:40:15 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 21 Jan 2016 23:40:15 -0500 Subject: [Smtk-developers] Development Workflows Message-ID: <758BB3C4-41FC-41C4-86BB-ED90A7DA7D20@kitware.com> Hi Folks, I'm looking into adding how to commit to CMB and SMTK and I was reading the workflows used in VTK and ParaView - do we want to use that workflow or the one we are currently using? Bob Sent from my iPad From ben.boeckel at kitware.com Wed Jan 27 11:34:05 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 27 Jan 2016 11:34:05 -0500 Subject: [Smtk-developers] SMTK's CMB plugins Message-ID: <20160127163405.GA13503@megas.kitware.com> So there's a problem with SMTK building CMB plugins, particularly on OS X. Plugins need to be installed in each .app bundle, but SMTK doesn't know what applications are going to be built. Here are three possible solutions: - move knowledge of applications to CMB's top-level so that SMTK can know where to install its bits to. Cons: CMB now has options at the wrong scope. SMTK has intimate knowledge of CMB. CMB with external SMTK is likely not going to work. Pros: smallest change - CMB does install(FILE) to install SMTK's plugins. Cons: Build tree won't work anymore (install_name_dir won't be fixed up with install(FILE)). Pros: No SMTK change. - Move CMB plugins into CMB itself. Cons: Most work. SMTK now has a bit of a split-brain for its plugins. Pros: CMB can do what it needs with the plugins for every platform. Thoughts? --Ben From bob.obara at kitware.com Wed Jan 27 11:55:53 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 27 Jan 2016 11:55:53 -0500 Subject: [Smtk-developers] SMTK's CMB plugins In-Reply-To: <20160127163405.GA13503@megas.kitware.com> References: <20160127163405.GA13503@megas.kitware.com> Message-ID: <3B2695E0-EC57-4907-A7AF-CA92B4EED46B@kitware.com> I vote for #3 - it doesn?t sound like its a ton of work. 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 Jan 27, 2016, at 11:34 AMEST, Ben Boeckel wrote: > > So there's a problem with SMTK building CMB plugins, particularly on OS > X. Plugins need to be installed in each .app bundle, but SMTK doesn't > know what applications are going to be built. Here are three possible > solutions: > > - move knowledge of applications to CMB's top-level so that SMTK can > know where to install its bits to. > Cons: > CMB now has options at the wrong scope. > SMTK has intimate knowledge of CMB. > CMB with external SMTK is likely not going to work. > Pros: > smallest change > > - CMB does install(FILE) to install SMTK's plugins. > Cons: > Build tree won't work anymore (install_name_dir won't be fixed > up with install(FILE)). > Pros: > No SMTK change. > > - Move CMB plugins into CMB itself. > Cons: > Most work. > SMTK now has a bit of a split-brain for its plugins. > Pros: > CMB can do what it needs with the plugins for every platform. > > Thoughts? > > --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 Jan 27 14:11:22 2016 From: david.thompson at kitware.com (David Thompson) Date: Wed, 27 Jan 2016 14:11:22 -0500 Subject: [Smtk-developers] SMTK's CMB plugins In-Reply-To: <20160127163405.GA13503@megas.kitware.com> References: <20160127163405.GA13503@megas.kitware.com> Message-ID: I am good with #2 or #3. My only concern with #3 is that then SMTK's "ParaView support" could run into problems down the road. (E.g., we write a PV plugin to expose SMTK readers in PV that is independent of ModelBuilder; then we would need those plugins to reside in the SMTK repo again.) David > So there's a problem with SMTK building CMB plugins, particularly on OS > X. Plugins need to be installed in each .app bundle, but SMTK doesn't > know what applications are going to be built. Here are three possible > solutions: > > - move knowledge of applications to CMB's top-level so that SMTK can > know where to install its bits to. > Cons: > CMB now has options at the wrong scope. > SMTK has intimate knowledge of CMB. > CMB with external SMTK is likely not going to work. > Pros: > smallest change > > - CMB does install(FILE) to install SMTK's plugins. > Cons: > Build tree won't work anymore (install_name_dir won't be fixed > up with install(FILE)). > Pros: > No SMTK change. > > - Move CMB plugins into CMB itself. > Cons: > Most work. > SMTK now has a bit of a split-brain for its plugins. > Pros: > CMB can do what it needs with the plugins for every platform. > > Thoughts? > > --Ben > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From ben.boeckel at kitware.com Wed Jan 27 14:21:26 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 27 Jan 2016 14:21:26 -0500 Subject: [Smtk-developers] SMTK's CMB plugins In-Reply-To: References: <20160127163405.GA13503@megas.kitware.com> Message-ID: <20160127192126.GA16524@megas.kitware.com> On Wed, Jan 27, 2016 at 14:11:22 -0500, David Thompson wrote: > I am good with #2 or #3. My only concern with #3 is that then SMTK's > "ParaView support" could run into problems down the road. (E.g., we > write a PV plugin to expose SMTK readers in PV that is independent of > ModelBuilder; then we would need those plugins to reside in the SMTK > repo again.) There's no reason they couldn't be separate plugins though, right? Making *ParaView* plugins in SMTK is fine since SMTK requires ParaView in that case, but CMB plugins are a circular dependency. --Ben From david.thompson at kitware.com Fri Jan 29 14:42:34 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 29 Jan 2016 14:42:34 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? Message-ID: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> Hi all, In order to generate relative paths for use in SMTK model files, I would like to bump the Boost version we require to 1.60.0 (which is brand new and includes additional boost::filesystem methods for generating relative paths). Are there any objections? Thanks, David From bob.obara at kitware.com Fri Jan 29 14:56:25 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Fri, 29 Jan 2016 14:56:25 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> Message-ID: <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> What about using kwsys::RelativePath ? 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 Jan 29, 2016, at 2:42 PMEST, David Thompson wrote: > > Hi all, > > In order to generate relative paths for use in SMTK model files, I would like to bump the Boost version we require to 1.60.0 (which is brand new and includes additional boost::filesystem methods for generating relative paths). > > Are there any objections? > > Thanks, > 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 yumin.yuan at kitware.com Fri Jan 29 14:56:38 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 29 Jan 2016 14:56:38 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> Message-ID: There seems to be a lot of various fixes from this release, and no api breakage, so +1 from me. Yumin On Fri, Jan 29, 2016 at 2:42 PM, David Thompson wrote: > Hi all, > > In order to generate relative paths for use in SMTK model files, I would > like to bump the Boost version we require to 1.60.0 (which is brand new and > includes additional boost::filesystem methods for generating relative > paths). > > Are there any objections? > > Thanks, > 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 Fri Jan 29 14:58:45 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 29 Jan 2016 14:58:45 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> Message-ID: > What about using kwsys::RelativePath ? SMTK does not require VTK (which is the only place we would inherit kwsys). I would rather make the relative path thing optional if you have an older boost than add another dependency. David From robert.maynard at kitware.com Fri Jan 29 15:43:23 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 29 Jan 2016 15:43:23 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> Message-ID: Personally I would be hesitant to upgrade our boost version for a feature that shouldn't be hard to replicate. On Fri, Jan 29, 2016 at 2:58 PM, David Thompson wrote: >> What about using kwsys::RelativePath ? > > SMTK does not require VTK (which is the only place we would inherit kwsys). > > I would rather make the relative path thing optional if you have an older boost than add another dependency. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From david.thompson at kitware.com Fri Jan 29 15:54:35 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 29 Jan 2016 15:54:35 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> Message-ID: > Personally I would be hesitant to upgrade our boost version for a > feature that shouldn't be hard to replicate. Except that there are many corner cases (*cough* Windows drive letters *cough*) that make it harder than you might think to replicate. Also, the only reason we rely on boost is the filesystem library (and soon polygon, but that is optional). So it seems odd to implement something that a library we depend on has implemented in a later revision. If we're going to do that, then we should eliminate the boost requirement and just use it optionally for polygon. :-) David > > > > On Fri, Jan 29, 2016 at 2:58 PM, David Thompson > wrote: >>> What about using kwsys::RelativePath ? >> >> SMTK does not require VTK (which is the only place we would inherit kwsys). >> >> I would rather make the relative path thing optional if you have an older boost than add another dependency. >> >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers From bob.obara at kitware.com Fri Jan 29 17:23:05 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Fri, 29 Jan 2016 17:23:05 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> Message-ID: <93FD8991-FC81-4BB5-BA1F-D94F8A9B5789@kitware.com> Eventually C++ 2017 wil have filesystem in it - just cant wait that long - If we can?t use 1.60 then we will have to use kwsys (or write our own) - does everything build with 1.60? 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 Jan 29, 2016, at 3:54 PMEST, David Thompson wrote: > >> Personally I would be hesitant to upgrade our boost version for a >> feature that shouldn't be hard to replicate. > > Except that there are many corner cases (*cough* Windows drive letters *cough*) that make it harder than you might think to replicate. > > Also, the only reason we rely on boost is the filesystem library (and soon polygon, but that is optional). So it seems odd to implement something that a library we depend on has implemented in a later revision. If we're going to do that, then we should eliminate the boost requirement and just use it optionally for polygon. :-) > > David > >> >> >> >> On Fri, Jan 29, 2016 at 2:58 PM, David Thompson >> wrote: >>>> What about using kwsys::RelativePath ? >>> >>> SMTK does not require VTK (which is the only place we would inherit kwsys). >>> >>> I would rather make the relative path thing optional if you have an older boost than add another dependency. >>> >>> 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 Fri Jan 29 17:26:31 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 29 Jan 2016 17:26:31 -0500 Subject: [Smtk-developers] Bump boost requirement to 1.60? In-Reply-To: <93FD8991-FC81-4BB5-BA1F-D94F8A9B5789@kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> <93FD8991-FC81-4BB5-BA1F-D94F8A9B5789@kitware.com> Message-ID: <4D6E94F5-8E7A-4C0F-825E-B615CDF876AF@kitware.com> > Eventually C++ 2017 wil have filesystem in it - just cant wait that long - If we can?t use 1.60 then we will have to use kwsys (or write our own) - does everything build with 1.60? SMTK and Remus certainly do. The only other packages that the superbuild says depend on Boost are ParaView and CMB. I haven't wiped my superbuild yet to try them because that takes a while... I will start it going before I take off. David From ben.boeckel at kitware.com Fri Jan 29 17:28:26 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 29 Jan 2016 17:28:26 -0500 Subject: [Smtk-developers] [Cmb-users] Bump boost requirement to 1.60? In-Reply-To: <4D6E94F5-8E7A-4C0F-825E-B615CDF876AF@kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> <93FD8991-FC81-4BB5-BA1F-D94F8A9B5789@kitware.com> <4D6E94F5-8E7A-4C0F-825E-B615CDF876AF@kitware.com> Message-ID: <20160129222826.GA8048@megas.kitware.com> On Fri, Jan 29, 2016 at 17:26:31 -0500, David Thompson wrote: > > Eventually C++ 2017 wil have filesystem in it - just cant wait that long - If we can?t use 1.60 then we will have to use kwsys (or write our own) - does everything build with 1.60? > > SMTK and Remus certainly do. The only other packages that the > superbuild says depend on Boost are ParaView and CMB. I haven't wiped > my superbuild yet to try them because that takes a while... I will > start it going before I take off. ParaView needs it for a plugin; probably disabled in CMB (or can be disabled). The dep is probably an artifact from the paraview superbuild. --Ben From david.thompson at kitware.com Fri Jan 29 17:50:57 2016 From: david.thompson at kitware.com (David Thompson) Date: Fri, 29 Jan 2016 17:50:57 -0500 Subject: [Smtk-developers] [Cmb-users] Bump boost requirement to 1.60? In-Reply-To: <20160129222826.GA8048@megas.kitware.com> References: <956D3A63-AB5D-46F8-BB61-847A546853A2@kitware.com> <6C6886AB-BDFC-4047-83EF-2EA986188E35@kitware.com> <93FD8991-FC81-4BB5-BA1F-D94F8A9B5789@kitware.com> <4D6E94F5-8E7A-4C0F-825E-B615CDF876AF@kitware.com> <20160129222826.GA8048@megas.kitware.com> Message-ID: <384FACE7-3C51-49E2-86EF-D0BBFB4A9491@kitware.com> Then everything should be OK as long as Amanda is OK with it. I've pushed a MR to SMTK and one for the CMB superbuild (to use the new boost). The build of the SMTK MR will fail until the superbuild is updated. Once we have the Boost thing figured out, I will add a MR to bump SMTK master->release and CMB to use the newer SMTK. David > On Jan 29, 2016, at 5:28 PM, Ben Boeckel wrote: > > On Fri, Jan 29, 2016 at 17:26:31 -0500, David Thompson wrote: >>> Eventually C++ 2017 wil have filesystem in it - just cant wait that long - If we can?t use 1.60 then we will have to use kwsys (or write our own) - does everything build with 1.60? >> >> SMTK and Remus certainly do. The only other packages that the >> superbuild says depend on Boost are ParaView and CMB. I haven't wiped >> my superbuild yet to try them because that takes a while... I will >> start it going before I take off. > > ParaView needs it for a plugin; probably disabled in CMB (or can be > disabled). The dep is probably an artifact from the paraview superbuild. > > --Ben From bob.obara at kitware.com Sun Jan 31 20:44:10 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sun, 31 Jan 2016 20:44:10 -0500 Subject: [Smtk-developers] Dealing with passwords in attributes Message-ID: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> We have a use case where we need prompt the user for a password in order to launch jobs. Requirements would include the following: 1. Hide the password while being typed 2. Note allow the password from being written out to the attribute file when being saved. In order to provide support I can either add a "role" parameter to the string item indicating it is a password or create a special item/item def. Obviously the first would be faster. Any comments? Bob Sent from my iPad