From david.thompson at kitware.com Mon Feb 1 08:36:54 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Feb 2016 08:36:54 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> Message-ID: <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> > We have a use case where we need prompt the user for a password in order to launch jobs. ... > 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. > ... > Any comments? If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]). David [1]: http://html5tutorial.info/html5-contact.php From john.tourtellott at kitware.com Mon Feb 1 10:12:21 2016 From: john.tourtellott at kitware.com (John Tourtellott) Date: Mon, 1 Feb 2016 10:12:21 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> Message-ID: I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html element, which has a "type" attribute that can be set to *many* different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag. On Mon, Feb 1, 2016 at 8:36 AM, David Thompson wrote: > > We have a use case where we need prompt the user for a password in order > to launch jobs. ... > > 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. > > ... > > Any comments? > > If adding a "role" adjective to items, I would add it to the base Item > time instead of just to String. It will be handy elsewhere just like in > HTML5 (where roles are used by browsers to modify touchscreen keyboards > depending on whether numbers, e-mail, or URLs are being entered[1]). > > David > > [1]: http://html5tutorial.info/html5-contact.php > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Mon Feb 1 10:38:00 2016 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 1 Feb 2016 10:38:00 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> Message-ID: I will vote for a new type of item. I am just concerned that our customers will ask for more in the future besides hiding the text (Even how to hide the text could have a couple ways). I can see this item is doing more than just hiding text. It will likely connect to some server for password verification, and handle things like security policy, etc. Yumin On Mon, Feb 1, 2016 at 10:12 AM, John Tourtellott < john.tourtellott at kitware.com> wrote: > I would vote for modifying StringItemDefinition to add either a boolean > flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, > Password). To me, the closest analog is the html element, which has > a "type" attribute that can be set to *many* different values -- e.g., > button, checkbox, color, date, file, hidden, radio, url -- as well > as"password" and the default "text". As for the many other "type" choices, > the ones relevant to simulation preprocessing are already handled > differently in SMTK; so I would go for the boolean flag. > > > On Mon, Feb 1, 2016 at 8:36 AM, David Thompson > wrote: > >> > We have a use case where we need prompt the user for a password in >> order to launch jobs. ... >> > 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. >> > ... >> > Any comments? >> >> If adding a "role" adjective to items, I would add it to the base Item >> time instead of just to String. It will be handy elsewhere just like in >> HTML5 (where roles are used by browsers to modify touchscreen keyboards >> depending on whether numbers, e-mail, or URLs are being entered[1]). >> >> David >> >> [1]: http://html5tutorial.info/html5-contact.php >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users >> > > > _______________________________________________ > 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 Mon Feb 1 11:46:54 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Feb 2016 11:46:54 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> Message-ID: <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> Hi John (and Yumin), I think the boolean is too restrictive; we will almost certainly come up with other roles that require special processing. (I am thinking of roles related to how input is accepted but that are not UI-specific. For example, indicating that a DoubleItem should be a point on a surface instead of in the interior; that informs the UI that a point selector will work but does not specify UI elements to achieve it.) So in that sense, I agree with Yumin that a single boolean is too narrow. However, I do not think there needs to be a separate class just for passwords (or any other role). David > On Feb 1, 2016, at 10:12 AM, John Tourtellott wrote: > > I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html element, which has a "type" attribute that can be set to many different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag. > > > On Mon, Feb 1, 2016 at 8:36 AM, David Thompson wrote: > > We have a use case where we need prompt the user for a password in order to launch jobs. ... > > 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. > > ... > > Any comments? > > If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]). > > David > > [1]: http://html5tutorial.info/html5-contact.php > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > From robert.maynard at kitware.com Mon Feb 1 11:50:28 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 1 Feb 2016 11:50:28 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> Message-ID: I am split on my thoughts on password being a separate class. I think that as the use case for passwords expand to include two-factor passwords, resetting forms, password creation and setup of requirements the idea of it being a class becomes stronger. On Mon, Feb 1, 2016 at 11:46 AM, David Thompson wrote: > Hi John (and Yumin), > > I think the boolean is too restrictive; we will almost certainly come up with other roles that require special processing. (I am thinking of roles related to how input is accepted but that are not UI-specific. For example, indicating that a DoubleItem should be a point on a surface instead of in the interior; that informs the UI that a point selector will work but does not specify UI elements to achieve it.) > > So in that sense, I agree with Yumin that a single boolean is too narrow. However, I do not think there needs to be a separate class just for passwords (or any other role). > > David > >> On Feb 1, 2016, at 10:12 AM, John Tourtellott wrote: >> >> I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html element, which has a "type" attribute that can be set to many different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag. >> >> >> On Mon, Feb 1, 2016 at 8:36 AM, David Thompson wrote: >> > We have a use case where we need prompt the user for a password in order to launch jobs. ... >> > 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. >> > ... >> > Any comments? >> >> If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]). >> >> David >> >> [1]: http://html5tutorial.info/html5-contact.php >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users >> > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From bob.obara at kitware.com Mon Feb 1 11:51:19 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 1 Feb 2016 11:51:19 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> Message-ID: <84D17C4A-7DD2-40DD-B758-D99574E78BDD@kitware.com> Hi David, But in that case the roles will be different for each data item - assuming that the roles are enumerations and not just strings. I?m wondering if your use case would be better served by creating a new item - ?geometric coordinate" that could have additional meta data (is it spatial or parametric, etc..). 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 Feb 1, 2016, at 11:46 AMEST, David Thompson wrote: > > Hi John (and Yumin), > > I think the boolean is too restrictive; we will almost certainly come up with other roles that require special processing. (I am thinking of roles related to how input is accepted but that are not UI-specific. For example, indicating that a DoubleItem should be a point on a surface instead of in the interior; that informs the UI that a point selector will work but does not specify UI elements to achieve it.) > > So in that sense, I agree with Yumin that a single boolean is too narrow. However, I do not think there needs to be a separate class just for passwords (or any other role). > > David > >> On Feb 1, 2016, at 10:12 AM, John Tourtellott wrote: >> >> I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html element, which has a "type" attribute that can be set to many different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag. >> >> >> On Mon, Feb 1, 2016 at 8:36 AM, David Thompson wrote: >>> We have a use case where we need prompt the user for a password in order to launch jobs. ... >>> 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. >>> ... >>> Any comments? >> >> If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]). >> >> David >> >> [1]: http://html5tutorial.info/html5-contact.php >> _______________________________________________ >> Cmb-users mailing list >> Cmb-users at computationalmodelbuilder.org >> http://public.kitware.com/mailman/listinfo/cmb-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Feb 1 11:56:26 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Feb 2016 11:56:26 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> Message-ID: <9E1847A5-0A8F-4ED1-9797-6D3C4DC436A1@kitware.com> > I am split on my thoughts on password being a separate class. I think > that as the use case for passwords expand to include two-factor > passwords, resetting forms, password creation and setup of > requirements the idea of it being a class becomes stronger. Those all seem like auxiliary classes related to the UI, I/O, or application, not something that would be part of the attribute class that stores the value. David > > On Mon, Feb 1, 2016 at 11:46 AM, David Thompson > wrote: >> Hi John (and Yumin), >> >> I think the boolean is too restrictive; we will almost certainly come up with other roles that require special processing. (I am thinking of roles related to how input is accepted but that are not UI-specific. For example, indicating that a DoubleItem should be a point on a surface instead of in the interior; that informs the UI that a point selector will work but does not specify UI elements to achieve it.) >> >> So in that sense, I agree with Yumin that a single boolean is too narrow. However, I do not think there needs to be a separate class just for passwords (or any other role). >> >> David >> >>> On Feb 1, 2016, at 10:12 AM, John Tourtellott wrote: >>> >>> I would vote for modifying StringItemDefinition to add either a boolean flag (IsPassword) or maybe a "type" enumeration with 2 choices (Text, Password). To me, the closest analog is the html element, which has a "type" attribute that can be set to many different values -- e.g., button, checkbox, color, date, file, hidden, radio, url -- as well as"password" and the default "text". As for the many other "type" choices, the ones relevant to simulation preprocessing are already handled differently in SMTK; so I would go for the boolean flag. >>> >>> >>> On Mon, Feb 1, 2016 at 8:36 AM, David Thompson wrote: >>>> We have a use case where we need prompt the user for a password in order to launch jobs. ... >>>> 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. >>>> ... >>>> Any comments? >>> >>> If adding a "role" adjective to items, I would add it to the base Item time instead of just to String. It will be handy elsewhere just like in HTML5 (where roles are used by browsers to modify touchscreen keyboards depending on whether numbers, e-mail, or URLs are being entered[1]). >>> >>> David >>> >>> [1]: http://html5tutorial.info/html5-contact.php >>> _______________________________________________ >>> Cmb-users mailing list >>> Cmb-users at computationalmodelbuilder.org >>> http://public.kitware.com/mailman/listinfo/cmb-users >>> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers From david.thompson at kitware.com Mon Feb 1 11:59:59 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Feb 2016 11:59:59 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: <84D17C4A-7DD2-40DD-B758-D99574E78BDD@kitware.com> References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> <84D17C4A-7DD2-40DD-B758-D99574E78BDD@kitware.com> Message-ID: > But in that case the roles will be different for each data item - assuming that the roles are enumerations and not just strings. I?m wondering if your use case would be better served by creating a new item - ?geometric coordinate" that could have additional meta data (is it spatial or parametric, etc..). I am fine with strings instead of enums as long as the strings are documented. :-) It does seem like we need to be careful to keep the UI out of the data. Passwords really are not UI-specific; the UI and I/O layers might build behavior for dealing with items in that role but most/all of that logic should not be part of the attribute itself. If none of the logic needs to go with the attribute, then I vote for avoiding a new class. David From david.thompson at kitware.com Mon Feb 1 13:35:07 2016 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Feb 2016 13:35:07 -0500 Subject: [Smtk-developers] [Cmb-users] Bump boost requirement to 1.60? In-Reply-To: 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> <384FACE7-3C51-49E2-86EF-D0BBFB4A9491@kitware.com> <97BB6719-7509-4C82-9ABE-EDB0A2B4EE04@kitware.com> Message-ID: Thanks David! 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 Feb 1, 2016, at 1:35 PMEST, David Thompson wrote: > >> Filigree should be fine with it as well. > > Great! Bob: I'll have MRs for the superbuild, CMB, and SMTK ready this afternoon. > > In fact, you should already be able to merge this: https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/94 which appears to have built over the weekend although I cannot see any dashboard entries for it. > > Thanks, > David > >> On 1/29/16, 4:50 PM, "Cmb-users on behalf of David Thompson" >> > david.thompson at kitware.com> wrote: >> >>> 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 >>> >>> _______________________________________________ >>> Cmb-users mailing list >>> Cmb-users at computationalmodelbuilder.org >>> Blockedhttp://public.kitware.com/mailman/listinfo/cmb-usersBlocked > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon Feb 1 13:58:03 2016 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 1 Feb 2016 13:58:03 -0500 Subject: [Smtk-developers] [Cmb-users] Dealing with passwords in attributes In-Reply-To: References: <7D77777D-6322-42C4-B56B-DB183A2BE09E@kitware.com> <65803F75-B18B-4A95-A819-1199F736B423@kitware.com> <019E470B-7698-4BCD-A713-C2A39EB172AD@kitware.com> <84D17C4A-7DD2-40DD-B758-D99574E78BDD@kitware.com> Message-ID: <2202F4DB-D680-44BE-AD6C-A3190EF6A056@kitware.com> OK - so I think this sounds like we could use more discussion on ?roles? in general so here is what I suggest: Add a ?private? property to item definition - it will have the following effect: 1. Will not write out values to attribute file 2. Hide the text w/r to the line edit widget. 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 Feb 1, 2016, at 11:59 AMEST, David Thompson wrote: > >> But in that case the roles will be different for each data item - assuming that the roles are enumerations and not just strings. I?m wondering if your use case would be better served by creating a new item - ?geometric coordinate" that could have additional meta data (is it spatial or parametric, etc..). > > I am fine with strings instead of enums as long as the strings are documented. :-) > > It does seem like we need to be careful to keep the UI out of the data. Passwords really are not UI-specific; the UI and I/O layers might build behavior for dealing with items in that role but most/all of that logic should not be part of the attribute itself. If none of the logic needs to go with the attribute, then I vote for avoiding a new class. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Feb 18 13:59:51 2016 From: david.thompson at kitware.com (David Thompson) Date: Thu, 18 Feb 2016 13:59:51 -0500 Subject: [Smtk-developers] Polygonal modeler Message-ID: <6A486B80-1B29-43E5-8400-A18BDAC8EE64@kitware.com> Hi Bob and Yumin, I've pushed a branch named "latest-polygon" to git at gitlab.kitware.com:dcthomp/smtk.git (my fork of SMTK) that 1. contains a "force create face" operator that takes in edges (by association), an array of per-edge orientations (+1 or -1), and optionally a "counts" item specifying offsets to allow holes and multiple faces to be created by one operation; 2. is rebased onto origin/master from yesterday; 3. has a Python test named "polygonForceCreateFace" that creates a face from edges+orientations (testCreationFromEdges) or from points (testCreationFromPoints) -- you can run it with "-I" at the end of the command line to look at it in interactive mode. Please let me know if there's anything else you need or you run into problems with it. David From Amanda.M.Hines at erdc.dren.mil Mon Feb 1 10:55:06 2016 From: Amanda.M.Hines at erdc.dren.mil (Hines, Amanda M ERDC-RDE-ITL-MS CIV) Date: Mon, 01 Feb 2016 15:55:06 -0000 Subject: [Smtk-developers] [Cmb-users] Bump boost requirement to 1.60? In-Reply-To: <384FACE7-3C51-49E2-86EF-D0BBFB4A9491@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> <384FACE7-3C51-49E2-86EF-D0BBFB4A9491@kitware.com> Message-ID: Filigree should be fine with it as well. Thanks Amanda On 1/29/16, 4:50 PM, "Cmb-users on behalf of David Thompson" wrote: >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 > >_______________________________________________ >Cmb-users mailing list >Cmb-users at computationalmodelbuilder.org >Blockedhttp://public.kitware.com/mailman/listinfo/cmb-usersBlocked