From mathieu.westphal at kitware.com Mon Jan 2 09:15:24 2017 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 2 Jan 2017 15:15:24 +0100 Subject: [vtk-developers] GL2PS image diffs In-Reply-To: References: Message-ID: I've pushed my MR, but i supose not all gl2ps baselines were concerned, so there is still a few of them that needs updating. Regards, Mathieu Westphal On Wed, Dec 21, 2016 at 2:32 PM, Ken Martin wrote: > Awesome! > > On Wed, Dec 21, 2016 at 8:31 AM, Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> I have a MR which touches these baselines anyway, so i will update these >> there anyway. >> https://gitlab.kitware.com/vtk/vtk/merge_requests/2283 >> >> Soon to be merged. >> >> Mathieu Westphal >> >> On Wed, Dec 21, 2016 at 2:11 PM, Ken Martin >> wrote: >> >>> For the ones where the test image looks reasonable, just a tad off I >>> think we should add a new MR with additional valid images. ala >>> >>> https://open.cdash.org/testDetails.php?test=510446018&build=4693540 >>> >>> I can do it if you want. >>> >>> >>> On Tue, Dec 20, 2016 at 10:39 AM, David Lonie >>> wrote: >>> >>>> Looks like the dashboard machines are missing some fonts that >>>> matplotlib uses. The machines will need to be updated or the tests turned >>>> off. >>>> >>>> On Tue, Dec 20, 2016 at 9:29 AM, Bill Lorensen >>> > wrote: >>>> >>>>> Folks, >>>>> >>>>> This merge request: >>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/2273 >>>>> >>>>> turned gl2ps on for some new platforms. There are lots of failed image >>>>> tests. This patch did fix an error. >>>>> >>>>> For example: >>>>> https://open.cdash.org/viewTest.php?onlyfailed&buildid=4692227 >>>>> >>>>> Not sure how to proceed. >>>>> >>>>> Bill >>>>> >>>>> -- >>>>> Unpaid intern in BillsBasement at noware dot com >>>>> _______________________________________________ >>>>> Powered by www.kitware.com >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Search the list archives at: http://markmail.org/search/?q= >>>>> vtk-developers >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the list archives at: http://markmail.org/search/?q= >>>> vtk-developers >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>> >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 <(518)%20371-3971> >>> >>> This communication, including all attachments, contains confidential and >>> legally privileged information, and it is intended only for the use of the >>> addressee. Access to this email by anyone else is unauthorized. If you are >>> not the intended recipient, any disclosure, copying, distribution or any >>> action taken in reliance on it is prohibited and may be unlawful. If you >>> received this communication in error please notify us immediately and >>> destroy the original message. Thank you. >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >> > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 <(518)%20371-3971> > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Jan 2 13:47:08 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 2 Jan 2017 13:47:08 -0500 Subject: [vtk-developers] valgrind dashboard entry missing In-Reply-To: References: Message-ID: Power went off in my office. karego-at is back up now. I expect it will report again tomorrow about noon. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Dec 30, 2016 at 12:36 PM, Bill Lorensen wrote: > The last valgrind report was December 23. > karego-at.kitwareUbuntu-Valgrind > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Jan 2 13:54:12 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 2 Jan 2017 13:54:12 -0500 Subject: [vtk-developers] valgrind dashboard entry missing In-Reply-To: References: Message-ID: Thanks! On Mon, Jan 2, 2017 at 1:47 PM, David E DeMarle wrote: > Power went off in my office. karego-at is back up now. I expect it will > report again tomorrow about noon. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Fri, Dec 30, 2016 at 12:36 PM, Bill Lorensen > wrote: >> >> The last valgrind report was December 23. >> karego-at.kitwareUbuntu-Valgrind >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From ken.martin at kitware.com Tue Jan 3 13:26:16 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 3 Jan 2017 13:26:16 -0500 Subject: [vtk-developers] Dashboard Message-ID: Given that the dashboard is a bit of a train wreck right now, it is probably best if the only merges are those that fix existing dashboard errors & warnings. -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Jan 3 13:47:49 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 3 Jan 2017 13:47:49 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: Message-ID: <20170103184749.1990615408@mail.rogue-research.com> On Tue, 3 Jan 2017 13:26:16 -0500, Ken Martin said: >Given that the dashboard is a bit of a train wreck right now, it is >probably best if the only merges are those that fix existing dashboard >errors & warnings. I can fix the warnings from my newer clang builds... Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ken.martin at kitware.com Tue Jan 3 13:55:03 2017 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 3 Jan 2017 13:55:03 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: <20170103184749.1990615408@mail.rogue-research.com> References: <20170103184749.1990615408@mail.rogue-research.com> Message-ID: Thanks, maybe more critical though there is a compile failure on bigmac that is related to the OSX 10.12 changes you made this summer. Specifically it seems like somehow the aliases you created are not being found. No clue what changed recently to cause this to start failing. If anyone else has an idea jump in. See https://open.cdash.org/viewBuildError.php?buildid=4706856 for an example #if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && !defined(VTK_DONT_MAP_10_12_ENUMS) // The 10.12 SDK made a bunch of enum names more logical, map old names to new names to continue supporting old SDKs. #define NSWindowStyleMaskBorderless NSBorderlessWindowMask #define NSWindowStyleMaskTitled NSTitledWindowMask #define NSWindowStyleMaskClosable NSClosableWindowMask #define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask #define NSWindowStyleMaskResizable NSResizableWindowMask #define NSEventModifierFlagShift NSShiftKeyMask #define NSEventModifierFlagControl NSControlKeyMask #define NSEventModifierFlagOption NSAlternateKeyMask #define NSEventModifierFlagCommand NSCommandKeyMask #define NSEventTypeKeyDown NSKeyDown #define NSEventTypeKeyUp NSKeyUp #define NSEventTypeApplicationDefined NSApplicationDefined #define NSEventTypeFlagsChanged NSFlagsChanged #endif On Tue, Jan 3, 2017 at 1:47 PM, Sean McBride wrote: > On Tue, 3 Jan 2017 13:26:16 -0500, Ken Martin said: > > >Given that the dashboard is a bit of a train wreck right now, it is > >probably best if the only merges are those that fix existing dashboard > >errors & warnings. > > I can fix the warnings from my newer clang builds... > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Tue Jan 3 14:00:47 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 3 Jan 2017 14:00:47 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 1:55 PM, Ken Martin wrote: > Thanks, maybe more critical though there is a compile failure on bigmac > that is related to the OSX 10.12 changes you made this summer. Specifically > it seems like somehow the aliases you created are not being found. No clue > what changed recently to cause this to start failing. If anyone else has an > idea jump in. > > See https://open.cdash.org/viewBuildError.php?buildid=4706856 for an > example > I know why it started failing. bigmac was updated to Sierra over the holidays. And the XCode version hasn't been updated yet (one major upgrade at a time). I don't know if the changes Sean made for Sierra assumed XCode 8 or not. If we want to go ahead and update XCode, let Marcus know. HTH, Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Jan 3 14:06:13 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Jan 2017 14:06:13 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 1:55 PM, Ken Martin wrote: > > Thanks, maybe more critical though there is a compile failure on bigmac that is related to the OSX 10.12 changes you made this summer. Specifically it seems like somehow the aliases you created are not being found. No clue what changed recently to cause this to start failing. If anyone else has an idea jump in. > > See https://open.cdash.org/viewBuildError.php?buildid=4706856 for an example > > #if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && !defined(VTK_DONT_MAP_10_12_ENUMS) > // The 10.12 SDK made a bunch of enum names more logical, map old names to new names to continue supporting old SDKs. > #define NSWindowStyleMaskBorderless NSBorderlessWindowMask > #define NSWindowStyleMaskTitled NSTitledWindowMask > #define NSWindowStyleMaskClosable NSClosableWindowMask > #define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask > #define NSWindowStyleMaskResizable NSResizableWindowMask > > #define NSEventModifierFlagShift NSShiftKeyMask > #define NSEventModifierFlagControl NSControlKeyMask > #define NSEventModifierFlagOption NSAlternateKeyMask > #define NSEventModifierFlagCommand NSCommandKeyMask > > #define NSEventTypeKeyDown NSKeyDown > #define NSEventTypeKeyUp NSKeyUp > #define NSEventTypeApplicationDefined NSApplicationDefined > #define NSEventTypeFlagsChanged NSFlagsChanged > #endif > I was just taking a quick look at this, and I think the problem lies in Rendering/OpenGL2/vtkCocoaMacOSXSDKCompatibility.h, I upgraded the machine to Sierra. It is using, #if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && !defined(VTK_DONT_MAP_10_12_ENUMS) // The 10.12 SDK made a bunch of enum names more logical, map old names to new names to continue supporting old SDKs. This looks like it only uses the OS version, but VTK is building against the 10.10 SDK. Maybe I am misreading it, but I would have thought this would need to use the SDK version, and not the OS version. Marcus From sean at rogue-research.com Tue Jan 3 14:16:25 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 3 Jan 2017 14:16:25 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> Message-ID: <20170103191625.1573429218@mail.rogue-research.com> On Tue, 3 Jan 2017 14:06:13 -0500, Marcus D. Hanwell said: >On Tue, Jan 3, 2017 at 1:55 PM, Ken Martin wrote: >> >> Thanks, maybe more critical though there is a compile failure on >bigmac that is related to the OSX 10.12 changes you made this summer. >Specifically it seems like somehow the aliases you created are not being >found. No clue what changed recently to cause this to start failing. If >anyone else has an idea jump in. >> >> See https://open.cdash.org/viewBuildError.php?buildid=4706856 for an example >> >> #if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && ! >defined(VTK_DONT_MAP_10_12_ENUMS) >> // The 10.12 SDK made a bunch of enum names more logical, map old >names to new names to continue supporting old SDKs. >> #define NSWindowStyleMaskBorderless NSBorderlessWindowMask >> #define NSWindowStyleMaskTitled NSTitledWindowMask >> #define NSWindowStyleMaskClosable NSClosableWindowMask >> #define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask >> #define NSWindowStyleMaskResizable NSResizableWindowMask >> >> #define NSEventModifierFlagShift NSShiftKeyMask >> #define NSEventModifierFlagControl NSControlKeyMask >> #define NSEventModifierFlagOption NSAlternateKeyMask >> #define NSEventModifierFlagCommand NSCommandKeyMask >> >> #define NSEventTypeKeyDown NSKeyDown >> #define NSEventTypeKeyUp NSKeyUp >> #define NSEventTypeApplicationDefined NSApplicationDefined >> #define NSEventTypeFlagsChanged NSFlagsChanged >> #endif >> >I was just taking a quick look at this, and I think the problem lies >in Rendering/OpenGL2/vtkCocoaMacOSXSDKCompatibility.h, I upgraded the >machine to Sierra. It is using, > >#if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && >!defined(VTK_DONT_MAP_10_12_ENUMS) > // The 10.12 SDK made a bunch of enum names more logical, map old >names to new names to continue supporting old SDKs. > >This looks like it only uses the OS version, but VTK is building >against the 10.10 SDK. Maybe I am misreading it, but I would have >thought this would need to use the SDK version, and not the OS >version. MAC_OS_X_VERSION_MAX_ALLOWED is the way to check the SDK. Basically: Sierra requires Xcode 8. Generally, a new OS X always requires a new Xcode. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Tue Jan 3 14:28:38 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Jan 2017 14:28:38 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: <20170103191625.1573429218@mail.rogue-research.com> References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 2:16 PM, Sean McBride wrote: > > On Tue, 3 Jan 2017 14:06:13 -0500, Marcus D. Hanwell said: > > >On Tue, Jan 3, 2017 at 1:55 PM, Ken Martin wrote: > >> > >> Thanks, maybe more critical though there is a compile failure on > >bigmac that is related to the OSX 10.12 changes you made this summer. > >Specifically it seems like somehow the aliases you created are not being > >found. No clue what changed recently to cause this to start failing. If > >anyone else has an idea jump in. > >> > >> See https://open.cdash.org/viewBuildError.php?buildid=4706856 for an example > >> > >> #if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && ! > >defined(VTK_DONT_MAP_10_12_ENUMS) > >> // The 10.12 SDK made a bunch of enum names more logical, map old > >names to new names to continue supporting old SDKs. > >> #define NSWindowStyleMaskBorderless NSBorderlessWindowMask > >> #define NSWindowStyleMaskTitled NSTitledWindowMask > >> #define NSWindowStyleMaskClosable NSClosableWindowMask > >> #define NSWindowStyleMaskMiniaturizable NSMiniaturizableWindowMask > >> #define NSWindowStyleMaskResizable NSResizableWindowMask > >> > >> #define NSEventModifierFlagShift NSShiftKeyMask > >> #define NSEventModifierFlagControl NSControlKeyMask > >> #define NSEventModifierFlagOption NSAlternateKeyMask > >> #define NSEventModifierFlagCommand NSCommandKeyMask > >> > >> #define NSEventTypeKeyDown NSKeyDown > >> #define NSEventTypeKeyUp NSKeyUp > >> #define NSEventTypeApplicationDefined NSApplicationDefined > >> #define NSEventTypeFlagsChanged NSFlagsChanged > >> #endif > >> > >I was just taking a quick look at this, and I think the problem lies > >in Rendering/OpenGL2/vtkCocoaMacOSXSDKCompatibility.h, I upgraded the > >machine to Sierra. It is using, > > > >#if (MAC_OS_X_VERSION_MAX_ALLOWED < 101200) && > >!defined(VTK_DONT_MAP_10_12_ENUMS) > > // The 10.12 SDK made a bunch of enum names more logical, map old > >names to new names to continue supporting old SDKs. > > > >This looks like it only uses the OS version, but VTK is building > >against the 10.10 SDK. Maybe I am misreading it, but I would have > >thought this would need to use the SDK version, and not the OS > >version. > > MAC_OS_X_VERSION_MAX_ALLOWED is the way to check the SDK. > > Basically: Sierra requires Xcode 8. Generally, a new OS X always requires a new Xcode. > I naively checked that I could compile things, and assumed I was good. As it said OS_X_VERSION rather than SDK_VERSION I figured it was referring to the OS version... We can upgrade XCode too and see if that helps. We will have to restore the old SDKs as Apple wipes them out every time - taking a look at it now. Marcus From sean at rogue-research.com Tue Jan 3 14:40:51 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 3 Jan 2017 14:40:51 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> Message-ID: <20170103194051.904591817@mail.rogue-research.com> On Tue, 3 Jan 2017 14:28:38 -0500, Marcus D. Hanwell said: >I naively checked that I could compile things, and assumed I was good. >As it said OS_X_VERSION rather than SDK_VERSION I figured it was >referring to the OS version... We can upgrade XCode too and see if >that helps. It should. >We will have to restore the old SDKs as Apple wipes them >out every time - taking a look at it now. Yeah, it's annoying that they no longer include older SDKs. But 99% of the time, you don't need anything but the current one. Why do you need older ones? Are you sure you do? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Tue Jan 3 14:50:50 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Jan 2017 14:50:50 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: <20170103194051.904591817@mail.rogue-research.com> References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 2:40 PM, Sean McBride wrote: > On Tue, 3 Jan 2017 14:28:38 -0500, Marcus D. Hanwell said: > >>I naively checked that I could compile things, and assumed I was good. >>As it said OS_X_VERSION rather than SDK_VERSION I figured it was >>referring to the OS version... We can upgrade XCode too and see if >>that helps. > > It should. It has nearly finished downloading, we shall see shortly. > >>We will have to restore the old SDKs as Apple wipes them >>out every time - taking a look at it now. > > Yeah, it's annoying that they no longer include older SDKs. But 99% of the time, you don't need anything but the current one. Why do you need older ones? Are you sure you do? > So that the binaries we ship work with older versions of the OS, or that is my understanding and why we have continued to do this. Marcus From marcus.hanwell at kitware.com Tue Jan 3 14:58:50 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Jan 2017 14:58:50 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 2:50 PM, Marcus D. Hanwell wrote: > On Tue, Jan 3, 2017 at 2:40 PM, Sean McBride wrote: >> On Tue, 3 Jan 2017 14:28:38 -0500, Marcus D. Hanwell said: >> >>>I naively checked that I could compile things, and assumed I was good. >>>As it said OS_X_VERSION rather than SDK_VERSION I figured it was >>>referring to the OS version... We can upgrade XCode too and see if >>>that helps. >> >> It should. > > It has nearly finished downloading, we shall see shortly. The XCode upgrade completed, I ran it, it finished installing components, and I restored the old SDKs manually - if we don't need them then I think we need to adjust some build scripts too. Marcus From sean at rogue-research.com Tue Jan 3 15:00:33 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 3 Jan 2017 15:00:33 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> Message-ID: <20170103200033.2096611485@mail.rogue-research.com> On Tue, 3 Jan 2017 14:50:50 -0500, Marcus D. Hanwell said: >So that the binaries we ship work with older versions of the OS, or >that is my understanding and why we have continued to do this. Ah, no, that's a common misconception. There is a different setting called "deployment target" that decides the oldest version of the OS that binaries will run on. It's called "CMAKE_OSX_DEPLOYMENT_TARGET" in cmake. So it's perfectly OK to use Xcode 8 with its 10.12 SDK but with deployment target set to say 10.9. Then your binary will work on >= 10.9. It's a much better choice than hacking your Xcode. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Tue Jan 3 15:19:28 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 3 Jan 2017 15:19:28 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: <20170103200033.2096611485@mail.rogue-research.com> References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> Message-ID: On Tue, Jan 3, 2017 at 3:00 PM, Sean McBride wrote: > On Tue, 3 Jan 2017 14:50:50 -0500, Marcus D. Hanwell said: > >>So that the binaries we ship work with older versions of the OS, or >>that is my understanding and why we have continued to do this. > > Ah, no, that's a common misconception. There is a different setting called "deployment target" that decides the oldest version of the OS that binaries will run on. It's called "CMAKE_OSX_DEPLOYMENT_TARGET" in cmake. So it's perfectly OK to use Xcode 8 with its 10.12 SDK but with deployment target set to say 10.9. Then your binary will work on >= 10.9. It's a much better choice than hacking your Xcode. > We should take a look at that then, I was still under the impression we needed to hack our XCode. I will leave it in place for now, and see what happens. Marcus From alexis.girault at kitware.com Tue Jan 3 16:23:29 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Tue, 3 Jan 2017 16:23:29 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> Message-ID: I've been confronted to this kind of XCode/SDK version issues, and even though I did not dig up much, I found this post which encouraged using the SDK of the same version that the deployment target, so I went with it and it worked well for me: http://stackoverflow.com/a/15092753 I listed which SDKs ships with each XCode as well as official download links in this google doc: https://docs.google.com/a/kitware.com/spreadsheets/d/16UBOr7wXHIqe4mxDXRSFVkJB2xzSw1Bba0VQjbHzSlU/edit?usp=sharing There is also some link to a couple scripts I have been using to fixup my xcode with the previous SDKs, the latest being XCodeLegacy: https://github.com/devernay/xcodelegacy hth, Alexis On Tue, Jan 3, 2017 at 3:19 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Tue, Jan 3, 2017 at 3:00 PM, Sean McBride > wrote: > > On Tue, 3 Jan 2017 14:50:50 -0500, Marcus D. Hanwell said: > > > >>So that the binaries we ship work with older versions of the OS, or > >>that is my understanding and why we have continued to do this. > > > > Ah, no, that's a common misconception. There is a different setting > called "deployment target" that decides the oldest version of the OS that > binaries will run on. It's called "CMAKE_OSX_DEPLOYMENT_TARGET" in cmake. > So it's perfectly OK to use Xcode 8 with its 10.12 SDK but with deployment > target set to say 10.9. Then your binary will work on >= 10.9. It's a > much better choice than hacking your Xcode. > > > We should take a look at that then, I was still under the impression > we needed to hack our XCode. I will leave it in place for now, and see > what happens. > > Marcus > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Jan 3 16:47:54 2017 From: sean at rogue-research.com (Sean McBride) Date: Tue, 3 Jan 2017 16:47:54 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103184749.1990615408@mail.rogue-research.com> <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> Message-ID: <20170103214754.1103381@mail.rogue-research.com> On Tue, 3 Jan 2017 16:23:29 -0500, Alexis Girault said: >I've been confronted to this kind of XCode/SDK version issues, and even >though I did not dig up much, I found this post which encouraged using the >SDK of the same version that the deployment target, so I went with it and >it worked well for me: http://stackoverflow.com/a/15092753 There are instances where building against an older SDK is preferable/necessary, and I lament that Apple no longer includes the last few SDKs in Xcode (instead only including the newest SDK). But for 99% of the time, using the newest SDK is all you need. Regardless of the SDK version you need, you should always be setting the deployment version to the oldest OS version you want to support at runtime. If you really need/want to build against an older SDK, then you can: 1) hack Xcode, and risk any incompatibilities/bugs that ensue. 2) use an older Xcode, which may also mean using an older macOS. This is where having a collection of buildbots/VMs comes in very handy. >I listed which SDKs ships with each XCode as well as official download >links in this google doc: >https://docs.google.com/a/kitware.com/spreadsheets/d/ >16UBOr7wXHIqe4mxDXRSFVkJB2xzSw1Bba0VQjbHzSlU/edit?usp=sharing Seems to require a google login. The wikipedia Xcode article also lists SDK versions included, example: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Wed Jan 4 12:53:40 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 4 Jan 2017 12:53:40 -0500 Subject: [vtk-developers] vtkRenderingOpenGLCxx-TestFBO valgrind defects Message-ID: I think these defects may need suppression? https://open.cdash.org/viewDynamicAnalysisFile.php?id=4526851 -- Unpaid intern in BillsBasement at noware dot com From robert.maynard at kitware.com Wed Jan 4 14:06:12 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 4 Jan 2017 14:06:12 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required Message-ID: As we start a new year, it is time to announce that we are planning on rolling out a series of updates to VTK that are starting with the update of the minimum required CMake version. We have chosen CMake 3.3 as the minimum required version for numerous reasons, the most important of those reasons being: - It is the first CMake release that offers C++11 support for all four major compilers ( GCC / MSVC / Clang / XCode ). [1] - The CMake version is sufficiently new enough that it allows for a cleaning of the existing CMake infrastructure. The current CMake minimum version requires VTK to maintain forks of numerous FindPackages and Modules that are part of newer CMake versions. - Supports HTTPS downloads, with all the official binaries come with support. Allowing for migration of external data to a HTTPS only server. Something we are going to require in the near future. [2] As mentioned above this year we have a series of upgrades planned to VTK which require moving the minimum CMake version to 3.3. The most significant of these changes to all developers is the requirement of a C++11 capable compiler. Yes you heard that correct, VTK is going to soon require a C++11 capable compiler. To be more exact we are going to require a compiler that understands the significant majority of the C++11 language and runtime additions. The exact versions for each compiler have not been set in stone, but a rough estimation would be: - GCC 4.8+ - Clang 3.3+ - XCode 5.0+ - MSVC 2013+ As we progress through the year, I expect a more concrete list of supported compilers will be determined and documented. Now the roll out for C++11 support is going to happen in multiple stages with an initial plan being: Stage 1: We require CMake 3.3, upgrade all dashboards, work through developer reported issues with the version bump Stage 2: Explicitly enable C++11 compiler flags during CMake configuration. Again we will have to upgrade/retire dashboards, work through developer reported issues. Stage 3: Update the VTK Coding Standards for C++11. Stage 4: Allow C++11 to be used in VTK ( outside currently permitted usage ). Notes: 1 - If you are using a different compiler vendor than one of those listed above please see if it is currently supported ( https://cmake.org/cmake/help/v3.7/manual/cmake-compile-features.7.html ). If the vendor is not explicitly listed please contact me, so we can discuss what options are available. 2 - https://data.kitware.com is transitioning to be the location for all external data, and requires a SSL connection. From mathieu.westphal at kitware.com Wed Jan 4 14:36:56 2017 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 4 Jan 2017 20:36:56 +0100 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: That's awesome ! Thanks for doing that ! Mathieu Westphal On Wed, Jan 4, 2017 at 8:06 PM, Robert Maynard wrote: > As we start a new year, it is time to announce that we are planning on > rolling out a series of updates to VTK that are starting with the update > of the minimum required CMake version. > > We have chosen CMake 3.3 as the minimum required version for numerous > reasons, > the most important of those reasons being: > > - It is the first CMake release that offers C++11 support for all four > major > compilers ( GCC / MSVC / Clang / XCode ). [1] > > - The CMake version is sufficiently new enough that it allows for a > cleaning > of the existing CMake infrastructure. The current CMake minimum version > requires VTK to maintain forks of numerous FindPackages and Modules that > are > part of newer CMake versions. > > - Supports HTTPS downloads, with all the official binaries come with > support. > Allowing for migration of external data to a HTTPS only server. > Something we > are going to require in the near future. [2] > > As mentioned above this year we have a series of upgrades planned to VTK > which > require moving the minimum CMake version to 3.3. The most significant > of these changes to all developers is the requirement of a C++11 capable > compiler. > > Yes you heard that correct, VTK is going to soon require a C++11 capable > compiler. To be more exact we are going to require a compiler that > understands > the significant majority of the C++11 language and runtime additions. The > exact > versions for each compiler have not been set in stone, but a rough > estimation > would be: > - GCC 4.8+ > - Clang 3.3+ > - XCode 5.0+ > - MSVC 2013+ > As we progress through the year, I expect a more concrete list of supported > compilers will be determined and documented. > > Now the roll out for C++11 support is going to happen in multiple stages > with an initial plan being: > > Stage 1: We require CMake 3.3, upgrade all dashboards, work through > developer > reported issues with the version bump > > Stage 2: Explicitly enable C++11 compiler flags during CMake > configuration. Again > we will have to upgrade/retire dashboards, work through developer > reported issues. > > Stage 3: Update the VTK Coding Standards for C++11. > > Stage 4: Allow C++11 to be used in VTK ( outside currently permitted usage > ). > > Notes: > > 1 - If you are using a different compiler vendor than one of those listed > above > please see if it is currently supported > ( https://cmake.org/cmake/help/v3.7/manual/cmake-compile- > features.7.html ). > If the vendor is not explicitly listed please contact me, so we can > discuss > what options are available. > > 2 - https://data.kitware.com is transitioning to be the location for all > external data, and requires a SSL connection. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jan 4 15:48:55 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 4 Jan 2017 13:48:55 -0700 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: Almost exactly three years after I upgraded the wrappers to read C++11 syntax :) On Wed, Jan 4, 2017 at 12:36 PM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > That's awesome ! Thanks for doing that ! > > > > Mathieu Westphal > > On Wed, Jan 4, 2017 at 8:06 PM, Robert Maynard > wrote: > >> As we start a new year, it is time to announce that we are planning on >> rolling out a series of updates to VTK that are starting with the update >> of the minimum required CMake version. >> >> We have chosen CMake 3.3 as the minimum required version for numerous >> reasons, >> the most important of those reasons being: >> >> - It is the first CMake release that offers C++11 support for all four >> major >> compilers ( GCC / MSVC / Clang / XCode ). [1] >> >> - The CMake version is sufficiently new enough that it allows for a >> cleaning >> of the existing CMake infrastructure. The current CMake minimum version >> requires VTK to maintain forks of numerous FindPackages and Modules >> that are >> part of newer CMake versions. >> >> - Supports HTTPS downloads, with all the official binaries come with >> support. >> Allowing for migration of external data to a HTTPS only server. >> Something we >> are going to require in the near future. [2] >> >> As mentioned above this year we have a series of upgrades planned to VTK >> which >> require moving the minimum CMake version to 3.3. The most significant >> of these changes to all developers is the requirement of a C++11 capable >> compiler. >> >> Yes you heard that correct, VTK is going to soon require a C++11 capable >> compiler. To be more exact we are going to require a compiler that >> understands >> the significant majority of the C++11 language and runtime additions. The >> exact >> versions for each compiler have not been set in stone, but a rough >> estimation >> would be: >> - GCC 4.8+ >> - Clang 3.3+ >> - XCode 5.0+ >> - MSVC 2013+ >> As we progress through the year, I expect a more concrete list of >> supported >> compilers will be determined and documented. >> >> Now the roll out for C++11 support is going to happen in multiple stages >> with an initial plan being: >> >> Stage 1: We require CMake 3.3, upgrade all dashboards, work through >> developer >> reported issues with the version bump >> >> Stage 2: Explicitly enable C++11 compiler flags during CMake >> configuration. Again >> we will have to upgrade/retire dashboards, work through developer >> reported issues. >> >> Stage 3: Update the VTK Coding Standards for C++11. >> >> Stage 4: Allow C++11 to be used in VTK ( outside currently permitted >> usage ). >> >> Notes: >> >> 1 - If you are using a different compiler vendor than one of those listed >> above >> please see if it is currently supported >> ( https://cmake.org/cmake/help/v3.7/manual/cmake-compile-featu >> res.7.html ). >> If the vendor is not explicitly listed please contact me, so we can >> discuss >> what options are available. >> >> 2 - https://data.kitware.com is transitioning to be the location for all >> external data, and requires a SSL connection. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Jan 4 16:49:21 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 4 Jan 2017 16:49:21 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: <20170103214754.1103381@mail.rogue-research.com> References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> Message-ID: <20170104214920.GB315@megas.kitware.com> On Tue, Jan 03, 2017 at 16:47:54 -0500, Sean McBride wrote: > There are instances where building against an older SDK is > preferable/necessary, and I lament that Apple no longer includes the Qt4 doesn't compile against 10.10 (though I have patches which have made it possible before, 10.9 has been the most reliable). I think a patch release was made for 10.11 (which we never updated to use), but I doubt 10.12 will get one at this point. > If you really need/want to build against an older SDK, then you can: > 1) hack Xcode, and risk any incompatibilities/bugs that ensue. Xcode is starting to reject older SDKs. I think that using an 10.8 SDK with Xcode 8 errors out before compilation even starts now. I think we can expect Apple to be more aggressive about rejecting older SDKs in the future. > 2) use an older Xcode, which may also mean using an older macOS. This > is where having a collection of buildbots/VMs comes in very handy. Yep, older Xcodes are starting to get marked that they "don't support" newer versions of macOS. --Ben From david.gobbi at gmail.com Wed Jan 4 17:32:12 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 4 Jan 2017 15:32:12 -0700 Subject: [vtk-developers] Dashboard In-Reply-To: <20170104214920.GB315@megas.kitware.com> References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> Message-ID: On Wed, Jan 4, 2017 at 2:49 PM, Ben Boeckel wrote: > > Qt4 doesn't compile against 10.10 (though I have patches which have made > it possible before, 10.9 has been the most reliable). I think a patch > release was made for 10.11 (which we never updated to use), but I doubt > 10.12 will get one at this point. > I've built projects with Qt4 on 10.12 with Xcode 8, if I recall correctly the issue was that Qt package wanted to install apps and plugins into forbidden areas of the filesystem (to /Developer/Applications/Qt and /usr/bin) but as long those pieces were installed elsewhere the build went fine. However, we still have two build machines here running 10.9 for legacy software. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jan 4 17:44:44 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 4 Jan 2017 15:44:44 -0700 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> Message-ID: On Wed, Jan 4, 2017 at 3:32 PM, David Gobbi wrote: > > I've built projects with Qt4 on 10.12 with Xcode 8, if I recall correctly > the issue > was that Qt package wanted to install apps and plugins into forbidden > areas of > the filesystem (to /Developer/Applications/Qt and /usr/bin) but as long > those > pieces were installed elsewhere the build went fine. However, we still > have two > build machines here running 10.9 for legacy software. > Small correction: The fact that Qt4 installs pieces into /Developer apparently wasn't part of the problem. The difficulty was just that Qt4 tried to install qmake et al into /usr/bin so I installed them into /usr/local/bin instead. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Jan 5 08:54:14 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Jan 2017 08:54:14 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: :) On Wed, Jan 4, 2017 at 3:48 PM, David Gobbi wrote: > Almost exactly three years after I upgraded the wrappers to read C++11 > syntax :) > > > On Wed, Jan 4, 2017 at 12:36 PM, Mathieu Westphal > wrote: >> >> That's awesome ! Thanks for doing that ! >> >> >> >> Mathieu Westphal >> >> On Wed, Jan 4, 2017 at 8:06 PM, Robert Maynard >> wrote: >>> >>> As we start a new year, it is time to announce that we are planning on >>> rolling out a series of updates to VTK that are starting with the update >>> of the minimum required CMake version. >>> >>> We have chosen CMake 3.3 as the minimum required version for numerous >>> reasons, >>> the most important of those reasons being: >>> >>> - It is the first CMake release that offers C++11 support for all four >>> major >>> compilers ( GCC / MSVC / Clang / XCode ). [1] >>> >>> - The CMake version is sufficiently new enough that it allows for a >>> cleaning >>> of the existing CMake infrastructure. The current CMake minimum version >>> requires VTK to maintain forks of numerous FindPackages and Modules >>> that are >>> part of newer CMake versions. >>> >>> - Supports HTTPS downloads, with all the official binaries come with >>> support. >>> Allowing for migration of external data to a HTTPS only server. >>> Something we >>> are going to require in the near future. [2] >>> >>> As mentioned above this year we have a series of upgrades planned to VTK >>> which >>> require moving the minimum CMake version to 3.3. The most significant >>> of these changes to all developers is the requirement of a C++11 capable >>> compiler. >>> >>> Yes you heard that correct, VTK is going to soon require a C++11 capable >>> compiler. To be more exact we are going to require a compiler that >>> understands >>> the significant majority of the C++11 language and runtime additions. The >>> exact >>> versions for each compiler have not been set in stone, but a rough >>> estimation >>> would be: >>> - GCC 4.8+ >>> - Clang 3.3+ >>> - XCode 5.0+ >>> - MSVC 2013+ >>> As we progress through the year, I expect a more concrete list of >>> supported >>> compilers will be determined and documented. >>> >>> Now the roll out for C++11 support is going to happen in multiple stages >>> with an initial plan being: >>> >>> Stage 1: We require CMake 3.3, upgrade all dashboards, work through >>> developer >>> reported issues with the version bump >>> >>> Stage 2: Explicitly enable C++11 compiler flags during CMake >>> configuration. Again >>> we will have to upgrade/retire dashboards, work through >>> developer >>> reported issues. >>> >>> Stage 3: Update the VTK Coding Standards for C++11. >>> >>> Stage 4: Allow C++11 to be used in VTK ( outside currently permitted >>> usage ). >>> >>> Notes: >>> >>> 1 - If you are using a different compiler vendor than one of those listed >>> above >>> please see if it is currently supported >>> ( >>> https://cmake.org/cmake/help/v3.7/manual/cmake-compile-features.7.html ). >>> If the vendor is not explicitly listed please contact me, so we can >>> discuss >>> what options are available. >>> >>> 2 - https://data.kitware.com is transitioning to be the location for all >>> external data, and requires a SSL connection. >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > From ken.martin at kitware.com Thu Jan 5 11:10:31 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 5 Jan 2017 11:10:31 -0500 Subject: [vtk-developers] Dashboards Message-ID: The dashboard looks better today. Not great, but definitely moving in the right direction. Thanks to everyone who pitched in. If you merge a topic in the next day or so please consider rebasing it on master to get a cleaner set of buildbot results and once merged please check the top two sections of the dashboard to see if any of the warnings or errors are related to your topic. I do have more dashboard fixes I plan to merge today that should cleanup a few more systems/tests so hopefully tomorrow will be even a tad better. Thanks Ken -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Jan 5 12:24:00 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 5 Jan 2017 12:24:00 -0500 Subject: [vtk-developers] Coding style question: pre vs post increment operators (i++ vs ++i) Message-ID: <20170105172400.1514770071@mail.rogue-research.com> Hi all, cppcheck has a warning where it suggests "performance: Prefer prefix ++/-- operators for non-primitive types": The LLVM coding standards, for example, have a similar policy (and explanation): cppcheck gives bazillions of such warnings in VTK and I originally suppressed them all. More recently, I now suppress only some folders, leaving the warning enabled for those folders where there are no warnings currently. This has the effect therefore of such warnings now popping up for new code or changes to previously warning-free code (as seen on the dashboard now). What do we want to do? Start preferring preincrement (for non-primitive types!) in new code? or I suppress the warning entirely? (When we start allowing C++11 using range-based for will eliminate many such increments, but leaving that aside...) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ben.boeckel at kitware.com Fri Jan 6 10:27:24 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 6 Jan 2017 10:27:24 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> Message-ID: <20170106152724.GC29697@megas.kitware.com> On Wed, Jan 04, 2017 at 15:32:12 -0700, David Gobbi wrote: > I've built projects with Qt4 on 10.12 with Xcode 8, if I recall correctly > the issue > was that Qt package wanted to install apps and plugins into forbidden areas > of > the filesystem (to /Developer/Applications/Qt and /usr/bin) but as long > those > pieces were installed elsewhere the build went fine. However, we still > have two > build machines here running 10.9 for legacy software. Do you remember what version of Qt4? 4.8.6 definitely doesn't like even 10.10's SDK. --Ben From david.gobbi at gmail.com Fri Jan 6 11:18:02 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 6 Jan 2017 09:18:02 -0700 Subject: [vtk-developers] Dashboard In-Reply-To: <20170106152724.GC29697@megas.kitware.com> References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> <20170106152724.GC29697@megas.kitware.com> Message-ID: On Fri, Jan 6, 2017 at 8:27 AM, Ben Boeckel wrote: > > > Do you remember what version of Qt4? 4.8.6 definitely doesn't like even > 10.10's SDK. It was qt-opensource-mac-4.8.6-1.dmg (I wasn't building Qt from source). I was using this on a 10.12 system with the "xcode 8.1 command line tools" rather than the full Xcode, though that shouldn't make a difference. CMake settings were as follows: CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.6 CMAKE_OSX_SYSROOT:STRING=/ The use of such an ancient target meant that "libstdc++" was used instead of the modern "libc++". This might be the reason that it worked. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Jan 6 11:43:49 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 6 Jan 2017 09:43:49 -0700 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103191625.1573429218@mail.rogue-research.com> <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> <20170106152724.GC29697@megas.kitware.com> Message-ID: On Fri, Jan 6, 2017 at 9:18 AM, David Gobbi wrote: > On Fri, Jan 6, 2017 at 8:27 AM, Ben Boeckel > wrote: >> >> >> Do you remember what version of Qt4? 4.8.6 definitely doesn't like even >> 10.10's SDK. > > > It was qt-opensource-mac-4.8.6-1.dmg (I wasn't building Qt from source). > I was using this on a 10.12 system with the "xcode 8.1 command line tools" > rather than the full Xcode, though that shouldn't make a difference. CMake > settings were as follows: > > CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.6 > CMAKE_OSX_SYSROOT:STRING=/ > > The use of such an ancient target meant that "libstdc++" was used instead > of the modern "libc++". This might be the reason that it worked. > I also explicitly added "-stdlib=libstdc++" to the CMAKE_CXX_FLAGS. In retrospect I don't think this was necessary for a target of 10.6, but it probably is necessary for a target of 10.9 when building against Qt 4.8. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Jan 6 14:12:39 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 6 Jan 2017 14:12:39 -0500 Subject: [vtk-developers] Dashboard In-Reply-To: References: <20170103194051.904591817@mail.rogue-research.com> <20170103200033.2096611485@mail.rogue-research.com> <20170103214754.1103381@mail.rogue-research.com> <20170104214920.GB315@megas.kitware.com> <20170106152724.GC29697@megas.kitware.com> Message-ID: <20170106191239.GA3581@megas.kitware.com> On Fri, Jan 06, 2017 at 09:18:02 -0700, David Gobbi wrote: > It was qt-opensource-mac-4.8.6-1.dmg (I wasn't building Qt from source). Ah, there are/were issues of the way 4.8.6 handles modal dialogs that trip up ParaView which is why we patch and build our own version. AFAICT, it was not appied before 4.8.6 (though it has been available on the issue tracker for a number few years now at this point). > The use of such an ancient target meant that "libstdc++" was used instead > of the modern "libc++". This might be the reason that it worked. It was more of Qt not understanding the way the bluetooth or wireless libraries got shuffled around in 10.10+ IIRC. --Ben From andrew.amaclean at gmail.com Fri Jan 6 16:02:50 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sat, 7 Jan 2017 08:02:50 +1100 Subject: [vtk-developers] Coding style question: pre vs post increment operators (i++ vs ++i) (Sean McBride) Message-ID: Hi Sean, In my opinion leave it in, we should start preferring preincrement, so don't suppress the warning.. The reasons are: 1) It alerts coders to performance issues. 2) VTK is huge and anything that improves the code base is a good thing as it makes future maintenance easier. 3) Warnings like this alert users to possible future issues. Where I have edited code, I have corrected issues like this. As an aside I also can't wait for range-based for loops and auto to be used in VTK! Roll on C++11. BTW Your coding standards link makes really interesting reading. Regards Andrew On Sat, Jan 7, 2017 at 4:00 AM, wrote: > Send vtk-developers mailing list submissions to > ---------- Forwarded message ---------- > From: Sean McBride > To: > Cc: > Date: Thu, 5 Jan 2017 12:24:00 -0500 > Subject: [vtk-developers] Coding style question: pre vs post increment > operators (i++ vs ++i) > Hi all, > > cppcheck has a warning where it suggests "performance: Prefer prefix ++/-- > operators for non-primitive types": > > > > The LLVM coding standards, for example, have a similar policy (and > explanation): > > > > cppcheck gives bazillions of such warnings in VTK and I originally > suppressed them all. More recently, I now suppress only some folders, > leaving the warning enabled for those folders where there are no warnings > currently. This has the effect therefore of such warnings now popping up > for new code or changes to previously warning-free code (as seen on the > dashboard now). > > What do we want to do? Start preferring preincrement (for non-primitive > types!) in new code? or I suppress the warning entirely? > > (When we start allowing C++11 using range-based for will eliminate many > such increments, but leaving that aside...) > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Jan 9 17:18:35 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 9 Jan 2017 17:18:35 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: We have merged in the branch to require CMake 3.3 today. So I will be keeping an eye on the dashboard machines and updating machines over the next couple of days. I also expect to have a MR open end of this week that will explicitly enable C++11 with a goal to have that merged in on Monday Jan 16. On Wed, Jan 4, 2017 at 2:06 PM, Robert Maynard wrote: > As we start a new year, it is time to announce that we are planning on > rolling out a series of updates to VTK that are starting with the update > of the minimum required CMake version. > > We have chosen CMake 3.3 as the minimum required version for numerous reasons, > the most important of those reasons being: > > - It is the first CMake release that offers C++11 support for all four major > compilers ( GCC / MSVC / Clang / XCode ). [1] > > - The CMake version is sufficiently new enough that it allows for a cleaning > of the existing CMake infrastructure. The current CMake minimum version > requires VTK to maintain forks of numerous FindPackages and Modules that are > part of newer CMake versions. > > - Supports HTTPS downloads, with all the official binaries come with support. > Allowing for migration of external data to a HTTPS only server. Something we > are going to require in the near future. [2] > > As mentioned above this year we have a series of upgrades planned to VTK which > require moving the minimum CMake version to 3.3. The most significant > of these changes to all developers is the requirement of a C++11 capable > compiler. > > Yes you heard that correct, VTK is going to soon require a C++11 capable > compiler. To be more exact we are going to require a compiler that understands > the significant majority of the C++11 language and runtime additions. The exact > versions for each compiler have not been set in stone, but a rough estimation > would be: > - GCC 4.8+ > - Clang 3.3+ > - XCode 5.0+ > - MSVC 2013+ > As we progress through the year, I expect a more concrete list of supported > compilers will be determined and documented. > > Now the roll out for C++11 support is going to happen in multiple stages > with an initial plan being: > > Stage 1: We require CMake 3.3, upgrade all dashboards, work through developer > reported issues with the version bump > > Stage 2: Explicitly enable C++11 compiler flags during CMake > configuration. Again > we will have to upgrade/retire dashboards, work through developer > reported issues. > > Stage 3: Update the VTK Coding Standards for C++11. > > Stage 4: Allow C++11 to be used in VTK ( outside currently permitted usage ). > > Notes: > > 1 - If you are using a different compiler vendor than one of those listed above > please see if it is currently supported > ( https://cmake.org/cmake/help/v3.7/manual/cmake-compile-features.7.html ). > If the vendor is not explicitly listed please contact me, so we can discuss > what options are available. > > 2 - https://data.kitware.com is transitioning to be the location for all > external data, and requires a SSL connection. From hahnse at ornl.gov Wed Jan 11 12:14:34 2017 From: hahnse at ornl.gov (Hahn, Steven E.) Date: Wed, 11 Jan 2017 17:14:34 +0000 Subject: [vtk-developers] Merge requests improving the performance of vtkCutter. Message-ID: <5B24E3AD-4B2D-41AC-A219-2AA2D07B7699@ornl.gov> I submitted three merge requests improving the performance of the vtkCutter filter used in ParaView?s Slice View. Would one or more trusted developers please review these changes? Use vtkArrayDispatch instead of vtkTemplateMacro in vtkGridSynchronizedTemplates3D https://gitlab.kitware.com/vtk/vtk/merge_requests/2332 Performance improvement by passing vtkDataArray to vtkImplicitFunction https://gitlab.kitware.com/vtk/vtk/merge_requests/2337 Improve efficiency of copying cell data inside vtkAppendPolyData. https://gitlab.kitware.com/vtk/vtk/merge_requests/2341 Thanks, Steven Hahn From david.gobbi at gmail.com Wed Jan 11 13:56:58 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 11 Jan 2017 11:56:58 -0700 Subject: [vtk-developers] TBB uses Apache license Message-ID: Hi All, Now that Intel has moved TBB from GPL to the Apache license, are there plans to include TBB as a third-party package in VTK 8.0? It looks like some work has already been done to add a cmake build system for it: https://github.com/wjakob/tbb Having TBB as a built-in would be very convenient for deployment. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From thehappydog84 at gmail.com Wed Jan 11 23:12:09 2017 From: thehappydog84 at gmail.com (Jon Garner) Date: Wed, 11 Jan 2017 23:12:09 -0500 Subject: [vtk-developers] New to Gitlab - pre-commit hook failure when trying to commit new files Message-ID: So I'm new around here and I've written a new class that I'd like to get onto Gitlab. (I'm also new to Git) If anyone could help me I'd greatly appreciate it. Here goes... 1.) I've gone through the process laid out here https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md . 2.) I've created a local clone of VTK 3.) Everything checks out when I run ./Utilities/SetupForDevelopment.sh. 4.) I have forked VTk into my Namespace on gitlab 5.) I've created a new topic/branch 6.) I added my .cxx and my .h file into the appropriate folder (then add using $git add) 7.) I also modify the CMakelists.txt file (I add it too) 7.) when I run $git commit I get the following Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) $ git commit pre-commit hook failure ----------------------- Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:66: trailing whitespace. + Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:75: tab in indent. + //draw a circle at nodes Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:76: tab in indent. + for(int j = 1; j < 30; j += 1) Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:77: tab in indent. + { Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:78: tab in indent. + for (int dotRad = 0; dotRad <= 3; dotRad += 1) Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:79: tab in indent. . . . until it reaches the end of the .cxx and the .h file then it just ends no mention of the .txt file. I tried pushing it and it sends the branch but the new files aren't there. I'm assuming it has something to do with the pre-commit hook failure. running $git status I get the following Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) $ git status On branch Implement_vtkInteractorStyleDrawPolygonType2 Changes to be committed: (use "git reset HEAD ..." to unstage) new file: Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx new file: Interaction/Style/vtkInteractorStyleDrawPolygonType2.h Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: Interaction/Style/CMakeLists.txt . . . running $git prepush it just returns no information is given. The next thing I intend to do is restore the CMakelist.txt change and see if that fixes the problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Jan 12 00:16:48 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 11 Jan 2017 22:16:48 -0700 Subject: [vtk-developers] New to Gitlab - pre-commit hook failure when trying to commit new files In-Reply-To: References: Message-ID: Hi Jon, Welcome to git (and VTK). When the commit hook says "tab in indent," it is disallowing the commit because your code contains tab characters. In other words, you tried to commit, but it refused. The "no tabs" rule is part of the basic "no changes should be invisible" guideline for code revision control. Let's say that you edited a file that was already in the repository, converted some of the 4-space indents to tab characters, and then pushed it back to the repository. To you, the code would look exactly the same, that is, the changes would be invisible to you. But the git revision log would show that a change had occurred. Also, to other developers who had their editor set to a 2-space (or 8-space) tabstop, the code would look very different. Your editor (assuming that it is a code editor and not a simple text editor) will have an option to convert tabs to spaces when you save the file. "Traling whitespace" or extra spaces at the end of a line are also forbidden, because they are generally invisible to the person who is editing the code, but they show up in the git revision logs. A good editor will either have an option to highlight this trailing whitespace so that you can remove it, or an option to automatically remove it when the the file is saved. In summary: you'll have to adjust your editor settings so that it writes files that conform to the pre-commit hook. - David On Wed, Jan 11, 2017 at 9:12 PM, Jon Garner wrote: > So I'm new around here and I've written a new class that I'd like to get > onto Gitlab. (I'm also new to Git) If anyone could help me I'd greatly > appreciate it. Here goes... > > 1.) I've gone through the process laid out here https://gitlab.kitware. > com/vtk/vtk/blob/master/Documentation/dev/git/develop.md. > 2.) I've created a local clone of VTK > 3.) Everything checks out when I run ./Utilities/SetupForDevelopment.sh. > 4.) I have forked VTk into my Namespace on gitlab > 5.) I've created a new topic/branch > 6.) I added my .cxx and my .h file into the appropriate folder (then add > using $git add) > 7.) I also modify the CMakelists.txt file (I add it too) > 7.) when I run $git commit I get the following > > Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) > $ git commit > pre-commit hook failure > ----------------------- > > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:66: trailing > whitespace. > + > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:75: tab in > indent. > + //draw a circle at nodes > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:76: tab in > indent. > + for(int j = 1; j < 30; j += 1) > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:77: tab in > indent. > + { > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:78: tab in > indent. > + for (int dotRad = 0; dotRad <= 3; dotRad += 1) > Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:79: tab in > indent. > . > . > . > > until it reaches the end of the .cxx and the .h file then it just ends no > mention of the .txt file. > > I tried pushing it and it sends the branch but the new files aren't > there. I'm assuming it has something to do with the pre-commit hook > failure. > > running $git status I get the following > > Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) > $ git status > On branch Implement_vtkInteractorStyleDrawPolygonType2 > Changes to be committed: > (use "git reset HEAD ..." to unstage) > > new file: Interaction/Style/vtkInteractorStyleDrawPolygonT > ype2.cxx > new file: Interaction/Style/vtkInteractorStyleDrawPolygonType2.h > > Changes not staged for commit: > (use "git add ..." to update what will be committed) > (use "git checkout -- ..." to discard changes in working directory) > > modified: Interaction/Style/CMakeLists.txt > . > . > . > > running $git prepush it just returns no information is given. > > The next thing I intend to do is restore the CMakelist.txt change and see > if that fixes the problem. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thehappydog84 at gmail.com Thu Jan 12 00:31:21 2017 From: thehappydog84 at gmail.com (Jon Garner) Date: Thu, 12 Jan 2017 00:31:21 -0500 Subject: [vtk-developers] New to Gitlab - pre-commit hook failure when trying to commit new files In-Reply-To: References: Message-ID: Ahhh... I should have emailed this last night, I don't think I would have figured that out. This is my first time doing really anything with any type of project (open source or otherwise), so thank you very much. On Thu, Jan 12, 2017 at 12:16 AM, David Gobbi wrote: > Hi Jon, > > Welcome to git (and VTK). When the commit hook says "tab in indent," it > is disallowing the commit because your code contains tab characters. In > other words, you tried to commit, but it refused. > > The "no tabs" rule is part of the basic "no changes should be invisible" > guideline for code revision control. Let's say that you edited a file that > was already in the repository, converted some of the 4-space indents to tab > characters, and then pushed it back to the repository. To you, the code > would look exactly the same, that is, the changes would be invisible to > you. But the git revision log would show that a change had occurred. > Also, to other developers who had their editor set to a 2-space (or > 8-space) tabstop, the code would look very different. > > Your editor (assuming that it is a code editor and not a simple text > editor) will have an option to convert tabs to spaces when you save the > file. > > "Traling whitespace" or extra spaces at the end of a line are also > forbidden, because they are generally invisible to the person who is > editing the code, but they show up in the git revision logs. A good editor > will either have an option to highlight this trailing whitespace so that > you can remove it, or an option to automatically remove it when the the > file is saved. > > In summary: you'll have to adjust your editor settings so that it writes > files that conform to the pre-commit hook. > > - David > > > On Wed, Jan 11, 2017 at 9:12 PM, Jon Garner > wrote: > >> So I'm new around here and I've written a new class that I'd like to get >> onto Gitlab. (I'm also new to Git) If anyone could help me I'd greatly >> appreciate it. Here goes... >> >> 1.) I've gone through the process laid out here https://gitlab.kitware.co >> m/vtk/vtk/blob/master/Documentation/dev/git/develop.md. >> 2.) I've created a local clone of VTK >> 3.) Everything checks out when I run ./Utilities/SetupForDevelopment.sh. >> >> 4.) I have forked VTk into my Namespace on gitlab >> 5.) I've created a new topic/branch >> 6.) I added my .cxx and my .h file into the appropriate folder (then add >> using $git add) >> 7.) I also modify the CMakelists.txt file (I add it too) >> 7.) when I run $git commit I get the following >> >> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >> $ git commit >> pre-commit hook failure >> ----------------------- >> >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:66: trailing >> whitespace. >> + >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:75: tab in >> indent. >> + //draw a circle at nodes >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:76: tab in >> indent. >> + for(int j = 1; j < 30; j += 1) >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:77: tab in >> indent. >> + { >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:78: tab in >> indent. >> + for (int dotRad = 0; dotRad <= 3; dotRad += 1) >> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:79: tab in >> indent. >> . >> . >> . >> >> until it reaches the end of the .cxx and the .h file then it just ends no >> mention of the .txt file. >> >> I tried pushing it and it sends the branch but the new files aren't >> there. I'm assuming it has something to do with the pre-commit hook >> failure. >> >> running $git status I get the following >> >> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >> $ git status >> On branch Implement_vtkInteractorStyleDrawPolygonType2 >> Changes to be committed: >> (use "git reset HEAD ..." to unstage) >> >> new file: Interaction/Style/vtkInteracto >> rStyleDrawPolygonType2.cxx >> new file: Interaction/Style/vtkInteracto >> rStyleDrawPolygonType2.h >> >> Changes not staged for commit: >> (use "git add ..." to update what will be committed) >> (use "git checkout -- ..." to discard changes in working >> directory) >> >> modified: Interaction/Style/CMakeLists.txt >> . >> . >> . >> >> running $git prepush it just returns no information is given. >> >> The next thing I intend to do is restore the CMakelist.txt change and see >> if that fixes the problem. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Thu Jan 12 02:10:59 2017 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Thu, 12 Jan 2017 08:10:59 +0100 Subject: [vtk-developers] New to Gitlab - pre-commit hook failure when trying to commit new files In-Reply-To: References: Message-ID: Hi Also, if i'm not mistaken, git diff should highlight trailing whitespaces, before your commit, allowing you to locate these problems easilly. Regards, Mathieu Westphal On Thu, Jan 12, 2017 at 6:31 AM, Jon Garner wrote: > Ahhh... I should have emailed this last night, I don't think I would have > figured that out. This is my first time doing really anything with any > type of project (open source or otherwise), so thank you very much. > > On Thu, Jan 12, 2017 at 12:16 AM, David Gobbi > wrote: > >> Hi Jon, >> >> Welcome to git (and VTK). When the commit hook says "tab in indent," it >> is disallowing the commit because your code contains tab characters. In >> other words, you tried to commit, but it refused. >> >> The "no tabs" rule is part of the basic "no changes should be invisible" >> guideline for code revision control. Let's say that you edited a file that >> was already in the repository, converted some of the 4-space indents to tab >> characters, and then pushed it back to the repository. To you, the code >> would look exactly the same, that is, the changes would be invisible to >> you. But the git revision log would show that a change had occurred. >> Also, to other developers who had their editor set to a 2-space (or >> 8-space) tabstop, the code would look very different. >> >> Your editor (assuming that it is a code editor and not a simple text >> editor) will have an option to convert tabs to spaces when you save the >> file. >> >> "Traling whitespace" or extra spaces at the end of a line are also >> forbidden, because they are generally invisible to the person who is >> editing the code, but they show up in the git revision logs. A good editor >> will either have an option to highlight this trailing whitespace so that >> you can remove it, or an option to automatically remove it when the the >> file is saved. >> >> In summary: you'll have to adjust your editor settings so that it writes >> files that conform to the pre-commit hook. >> >> - David >> >> >> On Wed, Jan 11, 2017 at 9:12 PM, Jon Garner >> wrote: >> >>> So I'm new around here and I've written a new class that I'd like to get >>> onto Gitlab. (I'm also new to Git) If anyone could help me I'd greatly >>> appreciate it. Here goes... >>> >>> 1.) I've gone through the process laid out here >>> https://gitlab.kitware.com/vtk/vtk/blob/master/Document >>> ation/dev/git/develop.md. >>> 2.) I've created a local clone of VTK >>> 3.) Everything checks out when I run ./Utilities/SetupForDevelopment.sh. >>> >>> 4.) I have forked VTk into my Namespace on gitlab >>> 5.) I've created a new topic/branch >>> 6.) I added my .cxx and my .h file into the appropriate folder (then add >>> using $git add) >>> 7.) I also modify the CMakelists.txt file (I add it too) >>> 7.) when I run $git commit I get the following >>> >>> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >>> $ git commit >>> pre-commit hook failure >>> ----------------------- >>> >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:66: trailing >>> whitespace. >>> + >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:75: tab in >>> indent. >>> + //draw a circle at nodes >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:76: tab in >>> indent. >>> + for(int j = 1; j < 30; j += 1) >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:77: tab in >>> indent. >>> + { >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:78: tab in >>> indent. >>> + for (int dotRad = 0; dotRad <= 3; dotRad += 1) >>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:79: tab in >>> indent. >>> . >>> . >>> . >>> >>> until it reaches the end of the .cxx and the .h file then it just ends >>> no mention of the .txt file. >>> >>> I tried pushing it and it sends the branch but the new files aren't >>> there. I'm assuming it has something to do with the pre-commit hook >>> failure. >>> >>> running $git status I get the following >>> >>> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >>> $ git status >>> On branch Implement_vtkInteractorStyleDrawPolygonType2 >>> Changes to be committed: >>> (use "git reset HEAD ..." to unstage) >>> >>> new file: Interaction/Style/vtkInteracto >>> rStyleDrawPolygonType2.cxx >>> new file: Interaction/Style/vtkInteracto >>> rStyleDrawPolygonType2.h >>> >>> Changes not staged for commit: >>> (use "git add ..." to update what will be committed) >>> (use "git checkout -- ..." to discard changes in working >>> directory) >>> >>> modified: Interaction/Style/CMakeLists.txt >>> . >>> . >>> . >>> >>> running $git prepush it just returns no information is given. >>> >>> The next thing I intend to do is restore the CMakelist.txt change and >>> see if that fixes the problem. >>> >>> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warfield at crl.med.harvard.edu Thu Jan 12 08:46:43 2017 From: warfield at crl.med.harvard.edu (Simon Warfield) Date: Thu, 12 Jan 2017 08:46:43 -0500 Subject: [vtk-developers] vtk-developers Digest, Vol 153, Issue 11 In-Reply-To: References: Message-ID: Dear David, I agree with you. --Simon > Date: Wed, 11 Jan 2017 11:56:58 -0700 > From: David Gobbi > To: VTK Developers > Subject: [vtk-developers] TBB uses Apache license > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi All, > > Now that Intel has moved TBB from GPL to the Apache license, are there > plans to include TBB as a third-party package in VTK 8.0? It looks like > some work has already been done to add a cmake build system for it: > https://github.com/wjakob/tbb > > Having TBB as a built-in would be very convenient for deployment. > > - David -- Simon K. Warfield, Ph.D. Thorne Griscom Chair and Professor of Radiology Harvard Medical School Director of Radiology Research Director Computational Radiology Laboratory Department of Radiology Boston Children's Hospital From thehappydog84 at gmail.com Thu Jan 12 03:38:07 2017 From: thehappydog84 at gmail.com (Jon Garner) Date: Thu, 12 Jan 2017 03:38:07 -0500 Subject: [vtk-developers] New to Gitlab - pre-commit hook failure when trying to commit new files In-Reply-To: References: Message-ID: Thanks Mathieu On Thu, Jan 12, 2017 at 2:10 AM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Hi > > Also, if i'm not mistaken, git diff should highlight trailing whitespaces, > before your commit, allowing you to locate these problems easilly. > > Regards, > > Mathieu Westphal > > On Thu, Jan 12, 2017 at 6:31 AM, Jon Garner > wrote: > >> Ahhh... I should have emailed this last night, I don't think I would >> have figured that out. This is my first time doing really anything with >> any type of project (open source or otherwise), so thank you very much. >> >> On Thu, Jan 12, 2017 at 12:16 AM, David Gobbi >> wrote: >> >>> Hi Jon, >>> >>> Welcome to git (and VTK). When the commit hook says "tab in indent," it >>> is disallowing the commit because your code contains tab characters. In >>> other words, you tried to commit, but it refused. >>> >>> The "no tabs" rule is part of the basic "no changes should be invisible" >>> guideline for code revision control. Let's say that you edited a file that >>> was already in the repository, converted some of the 4-space indents to tab >>> characters, and then pushed it back to the repository. To you, the code >>> would look exactly the same, that is, the changes would be invisible to >>> you. But the git revision log would show that a change had occurred. >>> Also, to other developers who had their editor set to a 2-space (or >>> 8-space) tabstop, the code would look very different. >>> >>> Your editor (assuming that it is a code editor and not a simple text >>> editor) will have an option to convert tabs to spaces when you save the >>> file. >>> >>> "Traling whitespace" or extra spaces at the end of a line are also >>> forbidden, because they are generally invisible to the person who is >>> editing the code, but they show up in the git revision logs. A good editor >>> will either have an option to highlight this trailing whitespace so that >>> you can remove it, or an option to automatically remove it when the the >>> file is saved. >>> >>> In summary: you'll have to adjust your editor settings so that it writes >>> files that conform to the pre-commit hook. >>> >>> - David >>> >>> >>> On Wed, Jan 11, 2017 at 9:12 PM, Jon Garner >>> wrote: >>> >>>> So I'm new around here and I've written a new class that I'd like to >>>> get onto Gitlab. (I'm also new to Git) If anyone could help me I'd greatly >>>> appreciate it. Here goes... >>>> >>>> 1.) I've gone through the process laid out here >>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Document >>>> ation/dev/git/develop.md. >>>> 2.) I've created a local clone of VTK >>>> 3.) Everything checks out when I run ./Utilities/SetupForDevelopment.sh. >>>> >>>> 4.) I have forked VTk into my Namespace on gitlab >>>> 5.) I've created a new topic/branch >>>> 6.) I added my .cxx and my .h file into the appropriate folder (then >>>> add using $git add) >>>> 7.) I also modify the CMakelists.txt file (I add it too) >>>> 7.) when I run $git commit I get the following >>>> >>>> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >>>> $ git commit >>>> pre-commit hook failure >>>> ----------------------- >>>> >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:66: trailing >>>> whitespace. >>>> + >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:75: tab in >>>> indent. >>>> + //draw a circle at nodes >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:76: tab in >>>> indent. >>>> + for(int j = 1; j < 30; j += 1) >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:77: tab in >>>> indent. >>>> + { >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:78: tab in >>>> indent. >>>> + for (int dotRad = 0; dotRad <= 3; dotRad += 1) >>>> Interaction/Style/vtkInteractorStyleDrawPolygonType2.cxx:79: tab in >>>> indent. >>>> . >>>> . >>>> . >>>> >>>> until it reaches the end of the .cxx and the .h file then it just ends >>>> no mention of the .txt file. >>>> >>>> I tried pushing it and it sends the branch but the new files aren't >>>> there. I'm assuming it has something to do with the pre-commit hook >>>> failure. >>>> >>>> running $git status I get the following >>>> >>>> Jon at Arnie MINGW64 ~/VTK (Implement_vtkInteractorStyleDrawPolygonType2) >>>> $ git status >>>> On branch Implement_vtkInteractorStyleDrawPolygonType2 >>>> Changes to be committed: >>>> (use "git reset HEAD ..." to unstage) >>>> >>>> new file: Interaction/Style/vtkInteracto >>>> rStyleDrawPolygonType2.cxx >>>> new file: Interaction/Style/vtkInteracto >>>> rStyleDrawPolygonType2.h >>>> >>>> Changes not staged for commit: >>>> (use "git add ..." to update what will be committed) >>>> (use "git checkout -- ..." to discard changes in working >>>> directory) >>>> >>>> modified: Interaction/Style/CMakeLists.txt >>>> . >>>> . >>>> . >>>> >>>> running $git prepush it just returns no information is given. >>>> >>>> The next thing I intend to do is restore the CMakelist.txt change and >>>> see if that fixes the problem. >>>> >>>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Jan 13 08:44:40 2017 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 13 Jan 2017 08:44:40 -0500 Subject: [vtk-developers] Agora Message-ID: Can someone take a look at VTK buildbot for agora? It seems to be failing to get data/valid images for a few days in a row now. CMake Error at /home/khq.kitware.com/kitware/buildbot/vtk-agora-linux-shared-release_icc_mpi_openmpi_tbb/source/CMake/ExternalData.cmake:1005 (message): Object MD5=3a09b79f491e1e9facc1e81a14e7889a not found at: http://midas3.kitware.com/midas/api/rest?method=midas.bitstream.download&checksum=3a09b79f491e1e9facc1e81a14e7889a&algorithm=MD5 (wrong hash MD5=a0a85923331d4faa2ba6ff130a19d946) http://www.vtk.org/files/ExternalData/MD5/3a09b79f491e1e9facc1e81a14e7889a ("Timeout was reached") Call Stack (most recent call first): /home/khq.kitware.com/kitware/buildbot/vtk-agora-linux-shared-release_icc_mpi_openmpi_tbb/source/CMake/ExternalData.cmake:1027 (_ExternalData_download_object) -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Jan 13 09:57:12 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 13 Jan 2017 09:57:12 -0500 Subject: [vtk-developers] testing mailing list, please ignore Message-ID: David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Jan 13 12:05:53 2017 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 13 Jan 2017 12:05:53 -0500 Subject: [vtk-developers] TBB uses Apache license In-Reply-To: References: Message-ID: I have a few concerns: * It may not be as trivial from build perspective. TBB has a few libraries, some of which we don't use. So the build would have to be configurable. * The TBB we bundle may end up stale. The way our other 3rd parties are often stale. This is especially relevant to TBB since it is updated to support latest processors (like the KNL). * I am not sure about his but I wonder if system deployed TBB versions are optimized. Intel bundles TBB with its compilers for example. They are also deployed on supercomputers etc. So I would recommend holding off for a while and figuring some of these things out first. Best, -berk On Wed, Jan 11, 2017 at 1:56 PM, David Gobbi wrote: > Hi All, > > Now that Intel has moved TBB from GPL to the Apache license, are there > plans to include TBB as a third-party package in VTK 8.0? It looks like > some work has already been done to add a cmake build system for it: > https://github.com/wjakob/tbb > > Having TBB as a built-in would be very convenient for deployment. > > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thehappydog84 at gmail.com Fri Jan 13 16:48:03 2017 From: thehappydog84 at gmail.com (Jon Garner) Date: Fri, 13 Jan 2017 16:48:03 -0500 Subject: [vtk-developers] Just making sure I submitted everything right Message-ID: This was my first submit to any open source project before so I'm just check to make sure I did this all right. My Merge request is linked below. I tagged a couple of people that had helped me when I was working through getting it all submitted, just thought I'd put this out there in case I should have tagged someone else. https://gitlab.kitware.com/vtk/vtk/merge_requests/2352 . . . Here's my commit notes of the class I submitted if anyone is interested. vtkInteractorStyleDrawPolygonType2 is an interactor style that will allow the user to draw a straight-line polygon in the render window using left mouse button clicks to create nodes. A straight-line is drawn from node to node. When the right mouse button is pressed, a SelectionChangedEvent will be fired. My intention in creating this style is to ultimately use it in conjunction with another class (that will need to be created) to create a polygonal selection tool to select specific points in point cloud data. As best as I could tell this capability doesn't exist in VTK and I noticed a few people asking for it. It is something I find critical when working with point cloud selection and I?m sure there are other applications where this could come in handy. Currently there is a vtkInteractorStyleDrawPolygon interactor style, I would consider this a 'DrawLasso' at least in comparison to other software naming conventions (photoshop), so I wasn't sure what to call this style so I went with 'DrawPolygonType2'. I figure that 'Type2' could be renamed to something more appropriate by someone more knowledgeable. The basic process for of the class is as follows: (1) Once the class is initiated (press 'o'... not sure if that is used for something else) it then starts looking for the OnLeftButtonDown event. (2) On the first OnLeftButtonDown the initial node is drawn and a toggle is triggered to allow OnMouseMove to begin. (3) OnMouseMove draws the whole polygon connecting the current mouse position back to the last node and the starting node with a straight line. (I'll return to this further down) (4) Each OnLeftButtonDown draws a new node at the cursor position. (5) OnRightButtonDown Invokes SelectionChangedEvent additionally it toggles the interactor style back to trackball camera, pressing 'o' does the toggle only. Issues I see and what I'd like to add/fix: (1) Issue: when Left Clicking very near the edge of the render window I sometimes get a crash, I think this is from the pixels being out of range I used similar conditions from vtkInteractorStyleDrawPolygon, but I do still get the crash. Need to work on this some more. (2) Issue/Feature: As mentioned in note (3) above the OnMouseMove draws the entire pixel array at every movement causing a flicker of the line. This is where my lack of knowledge of VTK isn't helping, I recall reading about layered rendering within VTK but I haven?t had time to dig back through the manual or examples to find what I'm looking for. What I?m thinking is the only thing that needs to be redrawn during OnMouseMove is the lines from the cursor to the first and last node(so use a separate Renderer or something in the same renderwindow?? I'm not sure, like I said I need to read and play around with stuff some more) (3) Feature: Eventually I'd like to be able to select a node and adjust it as needed. Haven't put a lot of thought into this, it'd just be nice. (4) Feature: Would like to be able to pan/zoom and keep the polygon in it's relative position (not a priority at all may come back to it once I get the selection class worked out), can explain further if anyone is interested. Thanks, Jon Garner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Sat Jan 14 17:07:17 2017 From: ken.martin at kitware.com (Ken Martin) Date: Sat, 14 Jan 2017 17:07:17 -0500 Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard failure) Message-ID: The buildbots are pretty clean except we have one failing test on eeloo related to Python https://open.cdash.org/testDetails.php?test=516490674&build=4724245 It fails comparing a None to an int while other machines running that test pass. So I suspect it has something to do with the build/version/settings of python on it. I tried fixing the None int comparison but then it moved to a different failure, once again reminding me that python still lacks the elegant grace of Visual Basic (I am so baiting python users with that one) https://gitlab.kitware.com/vtk/vtk/merge_requests/2359 Anyone have a thought on what the right fix is? Thanks! Ken -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sun Jan 15 16:17:30 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 16 Jan 2017 08:17:30 +1100 Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard failure) Message-ID: Hi Ken, I think the fix is this: if axis and axis > 0: This should work. It seems to me that you want to return the result of impl.op() if axis > 0. Regards Andrew ---------- Forwarded message ---------- > From: Ken Martin > To: VTK Developers > Cc: > Date: Sat, 14 Jan 2017 17:07:17 -0500 > Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard > failure) > > The buildbots are pretty clean except we have one failing test on eeloo > related to Python > > https://open.cdash.org/testDetails.php?test=516490674&build=4724245 > > It fails comparing a None to an int while other machines running that test > pass. So I suspect it has something to do with the build/version/settings > of python on it. I tried fixing the None int comparison but then it moved > to a different failure, once again reminding me that python still lacks the > elegant grace of Visual Basic (I am so baiting python users with that one) > > https://gitlab.kitware.com/vtk/vtk/merge_requests/2359 > > Anyone have a thought on what the right fix is? > > Thanks! > Ken > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 <(518)%20371-3971> > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sun Jan 15 16:41:21 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 16 Jan 2017 08:41:21 +1100 Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard failure) In-Reply-To: References: Message-ID: Unfortunately I don't have MPI installed so I can't test it. On Mon, Jan 16, 2017 at 8:17 AM, Andrew Maclean wrote: > Hi Ken, > I think the fix is this: > > if axis and axis > 0: > This should work. It seems to me that you want to return the result of > impl.op() if axis > 0. > > Regards > Andrew > > ---------- Forwarded message ---------- >> From: Ken Martin >> To: VTK Developers >> Cc: >> Date: Sat, 14 Jan 2017 17:07:17 -0500 >> Subject: [vtk-developers] Anyone know Python? (and can look at a >> dashboard failure) >> >> The buildbots are pretty clean except we have one failing test on eeloo >> related to Python >> >> https://open.cdash.org/testDetails.php?test=516490674&build=4724245 >> >> It fails comparing a None to an int while other machines running that >> test pass. So I suspect it has something to do with the >> build/version/settings of python on it. I tried fixing the None int >> comparison but then it moved to a different failure, once again reminding >> me that python still lacks the elegant grace of Visual Basic (I am so >> baiting python users with that one) >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/2359 >> >> Anyone have a thought on what the right fix is? >> >> Thanks! >> Ken >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 <(518)%20371-3971> >> >> This communication, including all attachments, contains confidential and >> legally privileged information, and it is intended only for the use of the >> addressee. Access to this email by anyone else is unauthorized. If you are >> not the intended recipient, any disclosure, copying, distribution or any >> action taken in reliance on it is prohibited and may be unlawful. If you >> received this communication in error please notify us immediately and >> destroy the original message. Thank you. >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sun Jan 15 16:49:47 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 16 Jan 2017 08:49:47 +1100 Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard failure) In-Reply-To: References: Message-ID: Sorry Ken I forgot to include you. I can't test it as I don't have MPI installed but there are two approaches: 1: if axis and axis > 0: This should work. It seems to me that you want to return the result of impl.op() if axis > 0. 2: If the *or* is correct then you can use: if type(axis) == type(None) or axis > 0: On Mon, Jan 16, 2017 at 8:41 AM, Andrew Maclean wrote: > Unfortunately I don't have MPI installed so I can't test it. > > On Mon, Jan 16, 2017 at 8:17 AM, Andrew Maclean > wrote: > >> Hi Ken, >> I think the fix is this: >> >> if axis and axis > 0: >> This should work. It seems to me that you want to return the result of >> impl.op() if axis > 0. >> >> Regards >> Andrew >> >> ---------- Forwarded message ---------- >>> From: Ken Martin >>> To: VTK Developers >>> Cc: >>> Date: Sat, 14 Jan 2017 17:07:17 -0500 >>> Subject: [vtk-developers] Anyone know Python? (and can look at a >>> dashboard failure) >>> >>> The buildbots are pretty clean except we have one failing test on eeloo >>> related to Python >>> >>> https://open.cdash.org/testDetails.php?test=516490674&build=4724245 >>> >>> It fails comparing a None to an int while other machines running that >>> test pass. So I suspect it has something to do with the >>> build/version/settings of python on it. I tried fixing the None int >>> comparison but then it moved to a different failure, once again reminding >>> me that python still lacks the elegant grace of Visual Basic (I am so >>> baiting python users with that one) >>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/2359 >>> >>> Anyone have a thought on what the right fix is? >>> >>> Thanks! >>> Ken >>> >>> -- >>> Ken Martin PhD >>> Chairman & CFO >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> 518 371 3971 <(518)%20371-3971> >>> >>> This communication, including all attachments, contains confidential and >>> legally privileged information, and it is intended only for the use of the >>> addressee. Access to this email by anyone else is unauthorized. If you are >>> not the intended recipient, any disclosure, copying, distribution or any >>> action taken in reliance on it is prohibited and may be unlawful. If you >>> received this communication in error please notify us immediately and >>> destroy the original message. Thank you. >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q= >>> vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Jan 16 14:13:01 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 16 Jan 2017 14:13:01 -0500 Subject: [vtk-developers] Missing `TestPStreamAMR.png` Message-ID: Folks, I am getting this warning message from CMake after update ParaView to use a more recent VTK. Any ideas (before I look deeper)? ============================================= CMake Warning (dev) at VTK/CMake/ExternalData.cmake:674 (message): Data file referenced by argument DATA{/home/utkarsh/Kitware/ParaView3/ParaView/VTK/Filters/ParallelFlowPaths/Testing/Data/Baseline/TestPStreamAMR.png,:} corresponds to source tree path VTK/Filters/ParallelFlowPaths/Testing/Data/Baseline/TestPStreamAMR.png that does not exist as a file (with or without an extension)! Call Stack (most recent call first): VTK/CMake/ExternalData.cmake:485 (_ExternalData_arg) VTK/CMake/ExternalData.cmake:340 (ExternalData_expand_arguments) VTK/CMake/vtkTestingMacros.cmake:175 (ExternalData_add_test) VTK/Filters/ParallelFlowPaths/Testing/Cxx/CMakeLists.txt:8 (vtk_add_test_mpi) This warning is for project developers. Use -Wno-dev to suppress it. Thanks From ken.martin at kitware.com Mon Jan 16 14:19:48 2017 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 16 Jan 2017 14:19:48 -0500 Subject: [vtk-developers] Missing `TestPStreamAMR.png` In-Reply-To: References: Message-ID: It is fixed in a yet more recent VTK. Basic gist is an mpi test was added that used data but didn't have a valid image. I updated the cmake list file to include the fact that the test has data, then realized it did not need or have a valid image and the mpi test macros did not support that case so I had to update those as well to support NO_VALID. All seems fine as of this morning's VTK IIRC. On Mon, Jan 16, 2017 at 2:13 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Folks, > > I am getting this warning message from CMake after update ParaView to > use a more recent VTK. Any ideas (before I look deeper)? > > ============================================= > CMake Warning (dev) at VTK/CMake/ExternalData.cmake:674 (message): > Data file referenced by argument > DATA{/home/utkarsh/Kitware/ParaView3/ParaView/VTK/ > Filters/ParallelFlowPaths/Testing/Data/Baseline/TestPStreamAMR.png,:} > > corresponds to source tree path > > VTK/Filters/ParallelFlowPaths/Testing/Data/Baseline/ > TestPStreamAMR.png > > that does not exist as a file (with or without an extension)! > Call Stack (most recent call first): > VTK/CMake/ExternalData.cmake:485 (_ExternalData_arg) > VTK/CMake/ExternalData.cmake:340 (ExternalData_expand_arguments) > VTK/CMake/vtkTestingMacros.cmake:175 (ExternalData_add_test) > VTK/Filters/ParallelFlowPaths/Testing/Cxx/CMakeLists.txt:8 > (vtk_add_test_mpi) > This warning is for project developers. Use -Wno-dev to suppress it. > > > > Thanks > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Jan 16 14:21:50 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 16 Jan 2017 14:21:50 -0500 Subject: [vtk-developers] Missing `TestPStreamAMR.png` In-Reply-To: References: Message-ID: Thanks! I'll update ParaView accordingly. Utkarsh On Mon, Jan 16, 2017 at 2:19 PM, Ken Martin wrote: > It is fixed in a yet more recent VTK. Basic gist is an mpi test was added > that used data but didn't have a valid image. I updated the cmake list file > to include the fact that the test has data, then realized it did not need or > have a valid image and the mpi test macros did not support that case so I > had to update those as well to support NO_VALID. All seems fine as of this > morning's VTK IIRC. > > On Mon, Jan 16, 2017 at 2:13 PM, Utkarsh Ayachit > wrote: >> >> Folks, >> >> I am getting this warning message from CMake after update ParaView to >> use a more recent VTK. Any ideas (before I look deeper)? >> >> ============================================= >> CMake Warning (dev) at VTK/CMake/ExternalData.cmake:674 (message): >> Data file referenced by argument >> >> DATA{/home/utkarsh/Kitware/ParaView3/ParaView/VTK/Filters/ParallelFlowPaths/Testing/Data/Baseline/TestPStreamAMR.png,:} >> >> corresponds to source tree path >> >> >> VTK/Filters/ParallelFlowPaths/Testing/Data/Baseline/TestPStreamAMR.png >> >> that does not exist as a file (with or without an extension)! >> Call Stack (most recent call first): >> VTK/CMake/ExternalData.cmake:485 (_ExternalData_arg) >> VTK/CMake/ExternalData.cmake:340 (ExternalData_expand_arguments) >> VTK/CMake/vtkTestingMacros.cmake:175 (ExternalData_add_test) >> VTK/Filters/ParallelFlowPaths/Testing/Cxx/CMakeLists.txt:8 >> (vtk_add_test_mpi) >> This warning is for project developers. Use -Wno-dev to suppress it. >> >> >> >> Thanks >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. From alexis.girault at kitware.com Mon Jan 16 16:47:55 2017 From: alexis.girault at kitware.com (Alexis Girault) Date: Mon, 16 Jan 2017 16:47:55 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: Awesome! Will there be any interest to transition to the c++11 smart pointers (shared, weak, unique)? Alexis On Mon, Jan 9, 2017 at 5:18 PM, Robert Maynard wrote: > We have merged in the branch to require CMake 3.3 today. So I will be > keeping an eye on the dashboard machines and updating machines over > the next couple of days. > > I also expect to have a MR open end of this week that will explicitly > enable C++11 with a goal to have that merged in on Monday Jan 16. > > On Wed, Jan 4, 2017 at 2:06 PM, Robert Maynard > wrote: > > As we start a new year, it is time to announce that we are planning on > > rolling out a series of updates to VTK that are starting with the update > > of the minimum required CMake version. > > > > We have chosen CMake 3.3 as the minimum required version for numerous > reasons, > > the most important of those reasons being: > > > > - It is the first CMake release that offers C++11 support for all four > major > > compilers ( GCC / MSVC / Clang / XCode ). [1] > > > > - The CMake version is sufficiently new enough that it allows for a > cleaning > > of the existing CMake infrastructure. The current CMake minimum version > > requires VTK to maintain forks of numerous FindPackages and Modules > that are > > part of newer CMake versions. > > > > - Supports HTTPS downloads, with all the official binaries come with > support. > > Allowing for migration of external data to a HTTPS only server. > Something we > > are going to require in the near future. [2] > > > > As mentioned above this year we have a series of upgrades planned to VTK > which > > require moving the minimum CMake version to 3.3. The most significant > > of these changes to all developers is the requirement of a C++11 capable > > compiler. > > > > Yes you heard that correct, VTK is going to soon require a C++11 capable > > compiler. To be more exact we are going to require a compiler that > understands > > the significant majority of the C++11 language and runtime additions. > The exact > > versions for each compiler have not been set in stone, but a rough > estimation > > would be: > > - GCC 4.8+ > > - Clang 3.3+ > > - XCode 5.0+ > > - MSVC 2013+ > > As we progress through the year, I expect a more concrete list of > supported > > compilers will be determined and documented. > > > > Now the roll out for C++11 support is going to happen in multiple stages > > with an initial plan being: > > > > Stage 1: We require CMake 3.3, upgrade all dashboards, work through > developer > > reported issues with the version bump > > > > Stage 2: Explicitly enable C++11 compiler flags during CMake > > configuration. Again > > we will have to upgrade/retire dashboards, work through > developer > > reported issues. > > > > Stage 3: Update the VTK Coding Standards for C++11. > > > > Stage 4: Allow C++11 to be used in VTK ( outside currently permitted > usage ). > > > > Notes: > > > > 1 - If you are using a different compiler vendor than one of those > listed above > > please see if it is currently supported > > ( https://cmake.org/cmake/help/v3.7/manual/cmake-compile- > features.7.html ). > > If the vendor is not explicitly listed please contact me, so we can > discuss > > what options are available. > > > > 2 - https://data.kitware.com is transitioning to be the location for all > > external data, and requires a SSL connection. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuaxo2 at yahoo.com Tue Jan 17 10:53:45 2017 From: stuaxo2 at yahoo.com (Stuart Axon) Date: Tue, 17 Jan 2017 15:53:45 +0000 (UTC) Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard failure) In-Reply-To: References: Message-ID: <1564384156.7267759.1484668425875@mail.yahoo.com> if type(axis) == type(None) or axis > 0: is not as idiomatic as: if axis is None or axis > 0: But this is totally fine too: if axis and axis > 0: ?S++ On Sunday, January 15, 2017 9:50 PM, Andrew Maclean wrote: Sorry Ken I forgot to include you. I can't test it as I don't have MPI installed but there are two approaches:1:if axis and axis > 0:?This should work. It seems to me that you want to return the result of impl.op() if axis > 0.2:If the?or?is correct then you can use:if type(axis) == type(None) or axis > 0: On Mon, Jan 16, 2017 at 8:41 AM, Andrew Maclean wrote: Unfortunately I don't have MPI installed so I can't test it. On Mon, Jan 16, 2017 at 8:17 AM, Andrew Maclean wrote: Hi Ken,? ?I think the fix is this: if axis and axis > 0:?This should work. It seems to me that you want to return the result of impl.op() if axis > 0. Regards ? ?Andrew ---------- Forwarded message ---------- From:?Ken Martin To:?VTK Developers Cc:? Date:?Sat, 14 Jan 2017 17:07:17 -0500 Subject:?[vtk-developers] Anyone know Python? (and can look at a dashboard failure) The buildbots are pretty clean except we have one failing test on eeloo related to Python https://open.cdash.org/testDet ails.php?test=516490674&build= 4724245 It fails comparing a None to an int while other machines running that test pass. So I suspect it has something to do with the build/version/settings of python on it. I tried fixing the None int comparison but then it moved to a different failure, once again reminding me that python still lacks the elegant grace of Visual Basic (I am so baiting python users with that one) https://gitlab.kitware.com/vtk /vtk/merge_requests/2359 Anyone have a thought on what the right fix is? Thanks!Ken -- Ken Martin PhDChairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 518 371 3971 This communication,including all attachments, contains confidential and legally privilegedinformation, and it is intended only for the use of the addressee.? Access to this email by anyone else isunauthorized. If you are not the intended recipient, any disclosure, copying,distribution or any action taken in reliance on it is prohibited and may beunlawful. If you received this communication in error please notify usimmediately and destroy the original message.?Thank you. ______________________________ _________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensou rce/opensource.html Search the list archives at: http://markmail.org/search/?q= vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mail man/listinfo/vtk-developers -- ______________________________ _____________ Andrew J. P. Maclean ______________________________ _____________ -- ______________________________ _____________ Andrew J. P. Maclean ______________________________ _____________ -- ______________________________ _____________ Andrew J. P. Maclean ______________________________ _____________ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jan 17 11:04:48 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 17 Jan 2017 11:04:48 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: Hi, I believe that the VTK object reference counting model is not well suited to a transition to c++11 shared pointer design. It would require a redesign of how everyone constructs VTK classes ( New, ShallowCopy, etc ) with no clear gain. VTK already uses an atomic ref count, and we don't need the shared_ptr overhead of holding the destructor. I do see value in VTK providing pre-made destructors for std::shared_ptr, etc so that you can safely mix the two different types of reference counting. On Mon, Jan 16, 2017 at 4:47 PM, Alexis Girault wrote: > Awesome! Will there be any interest to transition to the c++11 smart > pointers (shared, weak, unique)? > > Alexis > > On Mon, Jan 9, 2017 at 5:18 PM, Robert Maynard > wrote: >> >> We have merged in the branch to require CMake 3.3 today. So I will be >> keeping an eye on the dashboard machines and updating machines over >> the next couple of days. >> >> I also expect to have a MR open end of this week that will explicitly >> enable C++11 with a goal to have that merged in on Monday Jan 16. >> >> On Wed, Jan 4, 2017 at 2:06 PM, Robert Maynard >> wrote: >> > As we start a new year, it is time to announce that we are planning on >> > rolling out a series of updates to VTK that are starting with the update >> > of the minimum required CMake version. >> > >> > We have chosen CMake 3.3 as the minimum required version for numerous >> > reasons, >> > the most important of those reasons being: >> > >> > - It is the first CMake release that offers C++11 support for all four >> > major >> > compilers ( GCC / MSVC / Clang / XCode ). [1] >> > >> > - The CMake version is sufficiently new enough that it allows for a >> > cleaning >> > of the existing CMake infrastructure. The current CMake minimum >> > version >> > requires VTK to maintain forks of numerous FindPackages and Modules >> > that are >> > part of newer CMake versions. >> > >> > - Supports HTTPS downloads, with all the official binaries come with >> > support. >> > Allowing for migration of external data to a HTTPS only server. >> > Something we >> > are going to require in the near future. [2] >> > >> > As mentioned above this year we have a series of upgrades planned to VTK >> > which >> > require moving the minimum CMake version to 3.3. The most significant >> > of these changes to all developers is the requirement of a C++11 capable >> > compiler. >> > >> > Yes you heard that correct, VTK is going to soon require a C++11 capable >> > compiler. To be more exact we are going to require a compiler that >> > understands >> > the significant majority of the C++11 language and runtime additions. >> > The exact >> > versions for each compiler have not been set in stone, but a rough >> > estimation >> > would be: >> > - GCC 4.8+ >> > - Clang 3.3+ >> > - XCode 5.0+ >> > - MSVC 2013+ >> > As we progress through the year, I expect a more concrete list of >> > supported >> > compilers will be determined and documented. >> > >> > Now the roll out for C++11 support is going to happen in multiple stages >> > with an initial plan being: >> > >> > Stage 1: We require CMake 3.3, upgrade all dashboards, work through >> > developer >> > reported issues with the version bump >> > >> > Stage 2: Explicitly enable C++11 compiler flags during CMake >> > configuration. Again >> > we will have to upgrade/retire dashboards, work through >> > developer >> > reported issues. >> > >> > Stage 3: Update the VTK Coding Standards for C++11. >> > >> > Stage 4: Allow C++11 to be used in VTK ( outside currently permitted >> > usage ). >> > >> > Notes: >> > >> > 1 - If you are using a different compiler vendor than one of those >> > listed above >> > please see if it is currently supported >> > ( >> > https://cmake.org/cmake/help/v3.7/manual/cmake-compile-features.7.html ). >> > If the vendor is not explicitly listed please contact me, so we can >> > discuss >> > what options are available. >> > >> > 2 - https://data.kitware.com is transitioning to be the location for all >> > external data, and requires a SSL connection. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > From david.gobbi at gmail.com Tue Jan 17 11:52:02 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 17 Jan 2017 09:52:02 -0700 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: There's definitely a place for std::unique_ptr in VTK, however. There's lots of code that does local allocation with new/delete that could be cleaned up. Event binding is one place where we should detect the use of shared_ptr, i.e. the templated vtkObject::AddObserver method. I believe that the main thing holding us back from more widespread use of smart pointers is our rule for using forward declarations in VTK headers, rather than including other headers. And it's a rule that I don't want to see changed. - David On Tue, Jan 17, 2017 at 9:04 AM, Robert Maynard wrote: > Hi, > > I believe that the VTK object reference counting model is not well > suited to a transition to c++11 shared pointer design. It would > require a redesign of how everyone constructs VTK classes ( New, > ShallowCopy, etc ) with no clear gain. VTK already uses an atomic ref > count, and we don't need the shared_ptr overhead of holding the > destructor. > > I do see value in VTK providing pre-made destructors for > std::shared_ptr, etc so that you can safely mix the two different > types of reference counting. > > On Mon, Jan 16, 2017 at 4:47 PM, Alexis Girault > wrote: > > Awesome! Will there be any interest to transition to the c++11 smart > > pointers (shared, weak, unique)? > > > > Alexis > > > > On Mon, Jan 9, 2017 at 5:18 PM, Robert Maynard < > robert.maynard at kitware.com> > > wrote: > >> > >> We have merged in the branch to require CMake 3.3 today. So I will be > >> keeping an eye on the dashboard machines and updating machines over > >> the next couple of days. > >> > >> I also expect to have a MR open end of this week that will explicitly > >> enable C++11 with a goal to have that merged in on Monday Jan 16. > >> > >> On Wed, Jan 4, 2017 at 2:06 PM, Robert Maynard > >> wrote: > >> > As we start a new year, it is time to announce that we are planning on > >> > rolling out a series of updates to VTK that are starting with the > update > >> > of the minimum required CMake version. > >> > > >> > We have chosen CMake 3.3 as the minimum required version for numerous > >> > reasons, > >> > the most important of those reasons being: > >> > > >> > - It is the first CMake release that offers C++11 support for all four > >> > major > >> > compilers ( GCC / MSVC / Clang / XCode ). [1] > >> > > >> > - The CMake version is sufficiently new enough that it allows for a > >> > cleaning > >> > of the existing CMake infrastructure. The current CMake minimum > >> > version > >> > requires VTK to maintain forks of numerous FindPackages and Modules > >> > that are > >> > part of newer CMake versions. > >> > > >> > - Supports HTTPS downloads, with all the official binaries come with > >> > support. > >> > Allowing for migration of external data to a HTTPS only server. > >> > Something we > >> > are going to require in the near future. [2] > >> > > >> > As mentioned above this year we have a series of upgrades planned to > VTK > >> > which > >> > require moving the minimum CMake version to 3.3. The most significant > >> > of these changes to all developers is the requirement of a C++11 > capable > >> > compiler. > >> > > >> > Yes you heard that correct, VTK is going to soon require a C++11 > capable > >> > compiler. To be more exact we are going to require a compiler that > >> > understands > >> > the significant majority of the C++11 language and runtime additions. > >> > The exact > >> > versions for each compiler have not been set in stone, but a rough > >> > estimation > >> > would be: > >> > - GCC 4.8+ > >> > - Clang 3.3+ > >> > - XCode 5.0+ > >> > - MSVC 2013+ > >> > As we progress through the year, I expect a more concrete list of > >> > supported > >> > compilers will be determined and documented. > >> > > >> > Now the roll out for C++11 support is going to happen in multiple > stages > >> > with an initial plan being: > >> > > >> > Stage 1: We require CMake 3.3, upgrade all dashboards, work through > >> > developer > >> > reported issues with the version bump > >> > > >> > Stage 2: Explicitly enable C++11 compiler flags during CMake > >> > configuration. Again > >> > we will have to upgrade/retire dashboards, work through > >> > developer > >> > reported issues. > >> > > >> > Stage 3: Update the VTK Coding Standards for C++11. > >> > > >> > Stage 4: Allow C++11 to be used in VTK ( outside currently permitted > >> > usage ). > >> > > >> > Notes: > >> > > >> > 1 - If you are using a different compiler vendor than one of those > >> > listed above > >> > please see if it is currently supported > >> > ( > >> > https://cmake.org/cmake/help/v3.7/manual/cmake-compile- > features.7.html ). > >> > If the vendor is not explicitly listed please contact me, so we > can > >> > discuss > >> > what options are available. > >> > > >> > 2 - https://data.kitware.com is transitioning to be the location for > all > >> > external data, and requires a SSL connection. > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: http://markmail.org/search/?q= > vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Jan 17 12:04:19 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 17 Jan 2017 12:04:19 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 11:52 AM, David Gobbi wrote: > There's definitely a place for std::unique_ptr in VTK, however. There's > lots of code that does local allocation with new/delete that could be > cleaned up. Although vtkNew fills that role quite well too, and can be used with the other VTK smart pointers quite easily. For those that wanted to use unique_ptr it would be good to make that easy for them, but I wonder if tweaks to vtkNew would be preferable unless we make vtkObject derived classes behave more like normal C++ classes, i.e. removing implicit reference counting, allowing use of new/delete operators, managing memory using STL smart pointers. > > I believe that the main thing holding us back from more widespread use of > smart pointers is our rule for using forward declarations in VTK headers, > rather than including other headers. And it's a rule that I don't want to > see changed. > I thought it was also the design of the vtkObject base class, and the implicit reference counting. Unless we make very significant changes to the vtkObject hierarchy/design it would seem like a terrible idea to pay for implicit reference counting and for C++11 smart pointers. The use of the object factory mechanism forcing the use of the static New() also adds some overhead. From david.gobbi at gmail.com Tue Jan 17 12:15:17 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 17 Jan 2017 10:15:17 -0700 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 10:04 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Tue, Jan 17, 2017 at 11:52 AM, David Gobbi > wrote: > > There's definitely a place for std::unique_ptr in VTK, however. There's > > lots of code that does local allocation with new/delete that could be > > cleaned up. > > Although vtkNew fills that role quite well too, and can be used with > the other VTK smart pointers quite easily. For those that wanted to > use unique_ptr it would be good to make that easy for them, but I > wonder if tweaks to vtkNew would be preferable unless we make > vtkObject derived classes behave more like normal C++ classes, i.e. > removing implicit reference counting, allowing use of new/delete > operators, managing memory using STL smart pointers. > I wasn't even considering std::unique_ptr for VTK objects. I was more thinking of local allocation of memory for arrays and POD objects or legacy methods that return an alloc'd "char *" that needs to be deleted. > I believe that the main thing holding us back from more widespread use of > > smart pointers is our rule for using forward declarations in VTK headers, > > rather than including other headers. And it's a rule that I don't want > to > > see changed. > > > I thought it was also the design of the vtkObject base class, and the > implicit reference counting. Unless we make very significant changes > to the vtkObject hierarchy/design it would seem like a terrible idea > to pay for implicit reference counting and for C++11 smart pointers. > The use of the object factory mechanism forcing the use of the static > New() also adds some overhead. > Here I meant that, if it wasn't for our "no unnecessary header rule", we could use vtkSmartPointer to declare VTK class members and hence avoid calling ->Delete() in the destructors. I was using the term "smart pointer" in the broader sense, i.e. I was including the current vtkSmartPointer in the definition. Apologies for the confusion. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Jan 17 15:58:33 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 17 Jan 2017 15:58:33 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 12:15 PM, David Gobbi wrote: > On Tue, Jan 17, 2017 at 10:04 AM, Marcus D. Hanwell > wrote: >> >> On Tue, Jan 17, 2017 at 11:52 AM, David Gobbi >> wrote: >> > There's definitely a place for std::unique_ptr in VTK, however. There's >> > lots of code that does local allocation with new/delete that could be >> > cleaned up. >> >> Although vtkNew fills that role quite well too, and can be used with >> the other VTK smart pointers quite easily. For those that wanted to >> use unique_ptr it would be good to make that easy for them, but I >> wonder if tweaks to vtkNew would be preferable unless we make >> vtkObject derived classes behave more like normal C++ classes, i.e. >> removing implicit reference counting, allowing use of new/delete >> operators, managing memory using STL smart pointers. > > > I wasn't even considering std::unique_ptr for VTK objects. I was > more thinking of local allocation of memory for arrays and POD > objects or legacy methods that return an alloc'd "char *" that needs > to be deleted. > That makes more sense, and yes it would be great although some could be replaced with std::string, std::vector and other C++ containers. > >> > I believe that the main thing holding us back from more widespread use >> > of >> > smart pointers is our rule for using forward declarations in VTK >> > headers, >> > rather than including other headers. And it's a rule that I don't want >> > to >> > see changed. >> > >> I thought it was also the design of the vtkObject base class, and the >> implicit reference counting. Unless we make very significant changes >> to the vtkObject hierarchy/design it would seem like a terrible idea >> to pay for implicit reference counting and for C++11 smart pointers. >> The use of the object factory mechanism forcing the use of the static >> New() also adds some overhead. > > > Here I meant that, if it wasn't for our "no unnecessary header rule", > we could use vtkSmartPointer to declare VTK class members and > hence avoid calling ->Delete() in the destructors. I was using the > term "smart pointer" in the broader sense, i.e. I was including the > current vtkSmartPointer in the definition. Apologies for the confusion. > That is already the case, and I have modernized some classes. You can use vtkNew and vtkSmartPointer in class declarations, and we went to some effort to ensure they could be forward declared. Not to keep linking to it, but https://blog.kitware.com/a-tour-of-vtk-pointer-classes/ has an example of this being used in a class header with forward declared classes. I tested it before writing the article, and routinely use vtkNew and vtkSmartPointer in that context. From andrew.amaclean at gmail.com Tue Jan 17 16:12:18 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 18 Jan 2017 08:12:18 +1100 Subject: [vtk-developers] GitLab automatic merge not working. Message-ID: Hi All, Look at: https://gitlab.kitware.com/vtk/vtk/merge_requests/2377 This is the message that I am getting: ------- Automatic merge failed! *Error*: failed to merge the tree: ------- Does anyone know what is going wrong here and how to fix it? Sean is also having the same issue in: https://gitlab.kitware.com/vtk/vtk/merge_requests/2171 Regards Andrew ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Tue Jan 17 16:19:05 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 17 Jan 2017 16:19:05 -0500 Subject: [vtk-developers] GitLab automatic merge not working. In-Reply-To: References: Message-ID: Hi Andrew, It is a bug somewhere in the 'kitware robot' merge code. We see it happen off and on. Ben is working on it, so I pinged him on the merge requests in question and copied him on this.. Shawn On Tue, Jan 17, 2017 at 4:12 PM, Andrew Maclean wrote: > Hi All, > Look at: https://gitlab.kitware.com/vtk/vtk/merge_requests/2377 > > This is the message that I am getting: > ------- > > Automatic merge failed! > > *Error*: failed to merge the tree: > ------- > Does anyone know what is going wrong here and how to fix it? > Sean is also having the same issue in: > https://gitlab.kitware.com/vtk/vtk/merge_requests/2171 > > Regards > > Andrew > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jan 17 16:21:43 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 17 Jan 2017 14:21:43 -0700 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 1:58 PM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > > That is already the case, and I have modernized some classes. You can > use vtkNew and vtkSmartPointer in class declarations, and we went to > some effort to ensure they could be forward declared. > Well, then, there's a whole lot of egg on my face. I guess that since most of the classes that I maintain predated this, I never noticed that the newer classes were using smart pointers like this, hence I assumed that it wasn't possible. Because in my mind, I just couldn't image that such an important bit of code hygiene would be possible and at the same time not be used throughout VTK. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Jan 17 16:21:26 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 18 Jan 2017 08:21:26 +1100 Subject: [vtk-developers] Anyone know Python? (and can look at dashboard failure) Message-ID: Nice, thanks for pointing this out. Andrew ---------- Forwarded message ---------- > From: Stuart Axon > To: "andrew.amaclean at gmail.com" , VTK > Developers , Ken Martin > Cc: > Date: Tue, 17 Jan 2017 15:53:45 +0000 (UTC) > Subject: Re: [vtk-developers] Anyone know Python? (and can look at a > dashboard failure) > if type(axis) == type(None) or axis > 0: > > is not as idiomatic as: > > if axis is None or axis > 0: > > But this is totally fine too: > > if axis and axis > 0: > > > S++ > > > On Sunday, January 15, 2017 9:50 PM, Andrew Maclean < > andrew.amaclean at gmail.com> wrote: > > > > Sorry Ken I forgot to include you. > > I can't test it as I don't have MPI installed but there are two approaches: > 1: > if axis and axis > 0: > This should work. It seems to me that you want to return the result of > impl.op() if axis > 0. > 2: > If the *or* is correct then you can use: > if type(axis) == type(None) or axis > 0: > > On Mon, Jan 16, 2017 at 8:41 AM, Andrew Maclean > wrote: > > Unfortunately I don't have MPI installed so I can't test it. > > On Mon, Jan 16, 2017 at 8:17 AM, Andrew Maclean > wrote: > > Hi Ken, > I think the fix is this: > > if axis and axis > 0: > This should work. It seems to me that you want to return the result of > impl.op() if axis > 0. > > Regards > Andrew > > ---------- Forwarded message ---------- > From: Ken Martin > To: VTK Developers > Cc: > Date: Sat, 14 Jan 2017 17:07:17 -0500 > Subject: [vtk-developers] Anyone know Python? (and can look at a dashboard > failure) > > The buildbots are pretty clean except we have one failing test on eeloo > related to Python > > https://open.cdash.org/testDet ails.php?test=516490674&build= 4724245 > > > It fails comparing a None to an int while other machines running that test > pass. So I suspect it has something to do with the build/version/settings > of python on it. I tried fixing the None int comparison but then it moved > to a different failure, once again reminding me that python still lacks the > elegant grace of Visual Basic (I am so baiting python users with that one) > > https://gitlab.kitware.com/vtk /vtk/merge_requests/2359 > > > Anyone have a thought on what the right fix is? > > Thanks! > Ken > > -- > Ken Martin PhD > Chairman & CFO > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > 518 371 3971 > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > ______________________________ _________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q= vtk-developers > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mail man/listinfo/vtk-developers > > > > > > -- > ______________________________ _____________ > Andrew J. P. Maclean > > ______________________________ _____________ > > > > > -- > ______________________________ _____________ > Andrew J. P. Maclean > > ______________________________ _____________ > > > > > -- > ______________________________ _____________ > Andrew J. P. Maclean > > ______________________________ _____________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Jan 17 16:24:44 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 17 Jan 2017 16:24:44 -0500 Subject: [vtk-developers] GitLab automatic merge not working. In-Reply-To: References: Message-ID: <20170117212444.GA27080@megas.kitware.com> On Wed, Jan 18, 2017 at 08:12:18 +1100, Andrew Maclean wrote: > Hi All, > Look at: https://gitlab.kitware.com/vtk/vtk/merge_requests/2377 > > This is the message that I am getting: > ------- > > Automatic merge failed! > > *Error*: failed to merge the tree: > ------- > Does anyone know what is going wrong here and how to fix it? > Sean is also having the same issue in: > https://gitlab.kitware.com/vtk/vtk/merge_requests/2171 Yeah, sorry about that. The robot has been hiccupping at times with little to no indication of what went wrong; just ping me (or anyone else with Master and up permissions really) if you see it. --Ben From shawn.waldon at kitware.com Tue Jan 17 17:58:11 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 17 Jan 2017 17:58:11 -0500 Subject: [vtk-developers] Anyone know Python? (and can look at dashboard failure) In-Reply-To: References: Message-ID: Hi all, I talked with Berk about this one this morning and I have a MR that fixes it the bad comparisons [1]. Apparently I missed that the file also used xrange, so I just pushed an update to remove those. Shawn [1]: https://gitlab.kitware.com/vtk/vtk/merge_requests/2384 On Tue, Jan 17, 2017 at 4:21 PM, Andrew Maclean wrote: > Nice, thanks for pointing this out. > > Andrew > > ---------- Forwarded message ---------- >> From: Stuart Axon >> To: "andrew.amaclean at gmail.com" , VTK >> Developers , Ken Martin >> Cc: >> Date: Tue, 17 Jan 2017 15:53:45 +0000 (UTC) >> Subject: Re: [vtk-developers] Anyone know Python? (and can look at a >> dashboard failure) >> if type(axis) == type(None) or axis > 0: >> >> is not as idiomatic as: >> >> if axis is None or axis > 0: >> >> But this is totally fine too: >> >> if axis and axis > 0: >> >> >> S++ >> >> >> On Sunday, January 15, 2017 9:50 PM, Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >> >> >> Sorry Ken I forgot to include you. >> >> I can't test it as I don't have MPI installed but there are two >> approaches: >> 1: >> if axis and axis > 0: >> This should work. It seems to me that you want to return the result of >> impl.op() if axis > 0. >> 2: >> If the *or* is correct then you can use: >> if type(axis) == type(None) or axis > 0: >> >> On Mon, Jan 16, 2017 at 8:41 AM, Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >> Unfortunately I don't have MPI installed so I can't test it. >> >> On Mon, Jan 16, 2017 at 8:17 AM, Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >> Hi Ken, >> I think the fix is this: >> >> if axis and axis > 0: >> This should work. It seems to me that you want to return the result of >> impl.op() if axis > 0. >> >> Regards >> Andrew >> >> ---------- Forwarded message ---------- >> From: Ken Martin >> To: VTK Developers >> Cc: >> Date: Sat, 14 Jan 2017 17:07:17 -0500 >> Subject: [vtk-developers] Anyone know Python? (and can look at a >> dashboard failure) >> >> The buildbots are pretty clean except we have one failing test on eeloo >> related to Python >> >> https://open.cdash.org/testDet ails.php?test=516490674&build= 4724245 >> >> >> It fails comparing a None to an int while other machines running that >> test pass. So I suspect it has something to do with the >> build/version/settings of python on it. I tried fixing the None int >> comparison but then it moved to a different failure, once again reminding >> me that python still lacks the elegant grace of Visual Basic (I am so >> baiting python users with that one) >> >> https://gitlab.kitware.com/vtk /vtk/merge_requests/2359 >> >> >> Anyone have a thought on what the right fix is? >> >> Thanks! >> Ken >> >> -- >> Ken Martin PhD >> Chairman & CFO >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> 518 371 3971 >> >> This communication, including all attachments, contains confidential and >> legally privileged information, and it is intended only for the use of the >> addressee. Access to this email by anyone else is unauthorized. If you are >> not the intended recipient, any disclosure, copying, distribution or any >> action taken in reliance on it is prohibited and may be unlawful. If you >> received this communication in error please notify us immediately and >> destroy the original message. Thank you. >> >> ______________________________ _________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensou >> rce/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q= >> vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mail man/listinfo/vtk-developers >> >> >> >> >> >> -- >> ______________________________ _____________ >> Andrew J. P. Maclean >> >> ______________________________ _____________ >> >> >> >> >> -- >> ______________________________ _____________ >> Andrew J. P. Maclean >> >> ______________________________ _____________ >> >> >> >> >> -- >> ______________________________ _____________ >> Andrew J. P. Maclean >> >> ______________________________ _____________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Jan 17 22:53:11 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 17 Jan 2017 22:53:11 -0500 Subject: [vtk-developers] Plan to make CMake 3.3 and C++11 required In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 4:21 PM, David Gobbi wrote: > On Tue, Jan 17, 2017 at 1:58 PM, Marcus D. Hanwell > wrote: >> >> That is already the case, and I have modernized some classes. You can >> use vtkNew and vtkSmartPointer in class declarations, and we went to >> some effort to ensure they could be forward declared. > > Well, then, there's a whole lot of egg on my face. I guess that since > most of the classes that I maintain predated this, I never noticed that > the newer classes were using smart pointers like this, hence I assumed > that it wasn't possible. Because in my mind, I just couldn't image that > such an important bit of code hygiene would be possible and at the > same time not be used throughout VTK. > Glad I could clear it up, and I agree we should be using this far more widely. It is hard to automate though, and takes a fair bit of development time. I tend to spend more time on end user applications in recent years too. I wonder if we should make vtkNew automatically return its pointer as vtkSmartPointer does to encourage its use. I will see if I can update some more code. From bill.lorensen at gmail.com Wed Jan 18 09:28:18 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Jan 2017 09:28:18 -0500 Subject: [vtk-developers] Valgrind defects on the rise Message-ID: Folks, If you have recent merges, please check the dynamic memory analysis at the bottom of the dashboard. https://open.cdash.org/viewDynamicAnalysis.php?buildid=4728724 Bill -- Unpaid intern in BillsBasement at noware dot com From robert.maynard at kitware.com Wed Jan 18 12:11:21 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 18 Jan 2017 12:11:21 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 Message-ID: I am happy to announce that over the last two weeks we have rolled out a series of updates to VTK that mean the minimum required CMake version is now 3.3 (see below), and now builds with C+11 enabled. Yes VTK now requires a C++11 capable compiler. Initial we are only asking for a minimal set of C++11 features (nullptr), but as continue forward through the year we are going require a larger set of C++11 features. The final exact versions for each compiler have not been set in stone, but a rough estimation would be: - GCC 4.8+ - Clang 3.3+ - XCode 5.0+ - MSVC 2013+ I wanted to send this announcement out to bring up a couple of points: 1. Thanks to everyone that has helped get VTK ready for C++11! The final CMake switch over to C++11 was very easy, only because of all the hard work that other developers did in anticipation of this. So thank you very much. 2. The major reason for this slow roll out of C++11 is so that we minimize the impact on current VTK merge requests, while also minimizing dashboard instability. Contributors please be aware of these changes if you have long running branches. 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are currently working up a plan on how best to transition these machines to at least GCC 4.8 as the roll out continues. 4. The current MinGW dashboard machine doesn't support C++11 and will be removed, with no plan of a replacement at Kitware. If the community is interested in maintaining a newer MinGW machine I can provide assistance on how to setup a machine. ============ Why CMake 3.3: We have chosen CMake 3.3 as the minimum required version for numerous reasons, the most important of those reasons being: - It is the first CMake release that offers C++11 support for all four major compilers ( GCC / MSVC / Clang / XCode ). - The CMake version is sufficiently new enough that it allows for a cleaning of the existing CMake infrastructure. The current CMake minimum version requires VTK to maintain forks of numerous FindPackages and Modules that are part of newer CMake versions. - Supports HTTPS downloads, with all the official binaries come with support. Allowing for migration of external data to a HTTPS only server. Something we are going to require in the near future. From bill.lorensen at gmail.com Wed Jan 18 13:21:18 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Jan 2017 13:21:18 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: I have a computer with a non-c++11 compiler. I would expect a better error message. Something like: VTK requires a c++11 compiler. After update vtk I get these cmake errors "Clang" version 3.0.0. Call Stack (most recent call first): CMake/vtkModuleMacros.cmake:646 (vtk_add_library) Common/Core/CMakeLists.txt:724 (vtk_module_library) CMake Error at CMake/vtkModuleAPI.cmake:53 (message): No such module: "vtkCommonCore" Call Stack (most recent call first): CMake/vtkModuleAPI.cmake:15 (vtk_module_load) CMake/vtkModuleAPI.cmake:132 (_vtk_module_config_recurse) CMake/vtkModuleMacros.cmake:180 (vtk_module_config) CMake/vtkModuleMacros.cmake:582 (vtk_module_impl) Common/Math/CMakeLists.txt:40 (vtk_module_library) On Wed, Jan 18, 2017 at 12:11 PM, Robert Maynard wrote: > I am happy to announce that over the last two weeks we have rolled out a > series of updates to VTK that mean the minimum required CMake version > is now 3.3 (see below), and now builds with C+11 enabled. > > Yes VTK now requires a C++11 capable compiler. Initial we are only asking for a > minimal set of C++11 features (nullptr), but as continue forward through the > year we are going require a larger set of C++11 features. The final exact > versions for each compiler have not been set in stone, but a rough estimation > would be: > - GCC 4.8+ > - Clang 3.3+ > - XCode 5.0+ > - MSVC 2013+ > > I wanted to send this announcement out to bring up a couple of points: > > 1. Thanks to everyone that has helped get VTK ready for C++11! The final CMake > switch over to C++11 was very easy, only because of all the hard work that other > developers did in anticipation of this. So thank you very much. > > 2. The major reason for this slow roll out of C++11 is so that we minimize the > impact on current VTK merge requests, while also minimizing dashboard > instability. Contributors please be aware of these changes if you have long > running branches. > > 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are currently > working up a plan on how best to transition these machines to at least GCC 4.8 > as the roll out continues. > > 4. The current MinGW dashboard machine doesn't support C++11 and will be > removed, with no plan of a replacement at Kitware. If the community is > interested in maintaining a newer MinGW machine I can provide assistance > on how to setup a machine. > > > ============ > > Why CMake 3.3: > > We have chosen CMake 3.3 as the minimum required version for numerous reasons, > the most important of those reasons being: > > - It is the first CMake release that offers C++11 support for all four major > compilers ( GCC / MSVC / Clang / XCode ). > > - The CMake version is sufficiently new enough that it allows for a cleaning > of the existing CMake infrastructure. The current CMake minimum version > requires VTK to maintain forks of numerous FindPackages and Modules that are > part of newer CMake versions. > > - Supports HTTPS downloads, with all the official binaries come with support. > Allowing for migration of external data to a HTTPS only server. Something we > are going to require in the near future. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From robert.maynard at kitware.com Wed Jan 18 14:31:36 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 18 Jan 2017 14:31:36 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: I agree that the current error messages are not sufficient. I will work on a MR that provides better error reporting. On Wed, Jan 18, 2017 at 1:21 PM, Bill Lorensen wrote: > I have a computer with a non-c++11 compiler. I would expect a better > error message. > > Something like: VTK requires a c++11 compiler. > > After update vtk I get these cmake errors > "Clang" > > version 3.0.0. > Call Stack (most recent call first): > CMake/vtkModuleMacros.cmake:646 (vtk_add_library) > Common/Core/CMakeLists.txt:724 (vtk_module_library) > > > CMake Error at CMake/vtkModuleAPI.cmake:53 (message): > No such module: "vtkCommonCore" > Call Stack (most recent call first): > CMake/vtkModuleAPI.cmake:15 (vtk_module_load) > CMake/vtkModuleAPI.cmake:132 (_vtk_module_config_recurse) > CMake/vtkModuleMacros.cmake:180 (vtk_module_config) > CMake/vtkModuleMacros.cmake:582 (vtk_module_impl) > Common/Math/CMakeLists.txt:40 (vtk_module_library) > > > On Wed, Jan 18, 2017 at 12:11 PM, Robert Maynard > wrote: >> I am happy to announce that over the last two weeks we have rolled out a >> series of updates to VTK that mean the minimum required CMake version >> is now 3.3 (see below), and now builds with C+11 enabled. >> >> Yes VTK now requires a C++11 capable compiler. Initial we are only asking for a >> minimal set of C++11 features (nullptr), but as continue forward through the >> year we are going require a larger set of C++11 features. The final exact >> versions for each compiler have not been set in stone, but a rough estimation >> would be: >> - GCC 4.8+ >> - Clang 3.3+ >> - XCode 5.0+ >> - MSVC 2013+ >> >> I wanted to send this announcement out to bring up a couple of points: >> >> 1. Thanks to everyone that has helped get VTK ready for C++11! The final CMake >> switch over to C++11 was very easy, only because of all the hard work that other >> developers did in anticipation of this. So thank you very much. >> >> 2. The major reason for this slow roll out of C++11 is so that we minimize the >> impact on current VTK merge requests, while also minimizing dashboard >> instability. Contributors please be aware of these changes if you have long >> running branches. >> >> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are currently >> working up a plan on how best to transition these machines to at least GCC 4.8 >> as the roll out continues. >> >> 4. The current MinGW dashboard machine doesn't support C++11 and will be >> removed, with no plan of a replacement at Kitware. If the community is >> interested in maintaining a newer MinGW machine I can provide assistance >> on how to setup a machine. >> >> >> ============ >> >> Why CMake 3.3: >> >> We have chosen CMake 3.3 as the minimum required version for numerous reasons, >> the most important of those reasons being: >> >> - It is the first CMake release that offers C++11 support for all four major >> compilers ( GCC / MSVC / Clang / XCode ). >> >> - The CMake version is sufficiently new enough that it allows for a cleaning >> of the existing CMake infrastructure. The current CMake minimum version >> requires VTK to maintain forks of numerous FindPackages and Modules that are >> part of newer CMake versions. >> >> - Supports HTTPS downloads, with all the official binaries come with support. >> Allowing for migration of external data to a HTTPS only server. Something we >> are going to require in the near future. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > -- > Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Wed Jan 18 14:37:17 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 18 Jan 2017 14:37:17 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: Thanks, I can test it for you. On Jan 18, 2017 2:32 PM, "Robert Maynard" wrote: > I agree that the current error messages are not sufficient. I will > work on a MR that provides better error reporting. > > On Wed, Jan 18, 2017 at 1:21 PM, Bill Lorensen > wrote: > > I have a computer with a non-c++11 compiler. I would expect a better > > error message. > > > > Something like: VTK requires a c++11 compiler. > > > > After update vtk I get these cmake errors > > "Clang" > > > > version 3.0.0. > > Call Stack (most recent call first): > > CMake/vtkModuleMacros.cmake:646 (vtk_add_library) > > Common/Core/CMakeLists.txt:724 (vtk_module_library) > > > > > > CMake Error at CMake/vtkModuleAPI.cmake:53 (message): > > No such module: "vtkCommonCore" > > Call Stack (most recent call first): > > CMake/vtkModuleAPI.cmake:15 (vtk_module_load) > > CMake/vtkModuleAPI.cmake:132 (_vtk_module_config_recurse) > > CMake/vtkModuleMacros.cmake:180 (vtk_module_config) > > CMake/vtkModuleMacros.cmake:582 (vtk_module_impl) > > Common/Math/CMakeLists.txt:40 (vtk_module_library) > > > > > > On Wed, Jan 18, 2017 at 12:11 PM, Robert Maynard > > wrote: > >> I am happy to announce that over the last two weeks we have rolled out a > >> series of updates to VTK that mean the minimum required CMake version > >> is now 3.3 (see below), and now builds with C+11 enabled. > >> > >> Yes VTK now requires a C++11 capable compiler. Initial we are only > asking for a > >> minimal set of C++11 features (nullptr), but as continue forward > through the > >> year we are going require a larger set of C++11 features. The final > exact > >> versions for each compiler have not been set in stone, but a rough > estimation > >> would be: > >> - GCC 4.8+ > >> - Clang 3.3+ > >> - XCode 5.0+ > >> - MSVC 2013+ > >> > >> I wanted to send this announcement out to bring up a couple of points: > >> > >> 1. Thanks to everyone that has helped get VTK ready for C++11! The > final CMake > >> switch over to C++11 was very easy, only because of all the hard work > that other > >> developers did in anticipation of this. So thank you very much. > >> > >> 2. The major reason for this slow roll out of C++11 is so that we > minimize the > >> impact on current VTK merge requests, while also minimizing dashboard > >> instability. Contributors please be aware of these changes if you have > long > >> running branches. > >> > >> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are > currently > >> working up a plan on how best to transition these machines to at least > GCC 4.8 > >> as the roll out continues. > >> > >> 4. The current MinGW dashboard machine doesn't support C++11 and will be > >> removed, with no plan of a replacement at Kitware. If the community is > >> interested in maintaining a newer MinGW machine I can provide assistance > >> on how to setup a machine. > >> > >> > >> ============ > >> > >> Why CMake 3.3: > >> > >> We have chosen CMake 3.3 as the minimum required version for numerous > reasons, > >> the most important of those reasons being: > >> > >> - It is the first CMake release that offers C++11 support for all four > major > >> compilers ( GCC / MSVC / Clang / XCode ). > >> > >> - The CMake version is sufficiently new enough that it allows for a > cleaning > >> of the existing CMake infrastructure. The current CMake minimum > version > >> requires VTK to maintain forks of numerous FindPackages and Modules > that are > >> part of newer CMake versions. > >> > >> - Supports HTTPS downloads, with all the official binaries come with > support. > >> Allowing for migration of external data to a HTTPS only server. > Something we > >> are going to require in the near future. > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > >> > >> Search the list archives at: http://markmail.org/search/?q= > vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Jan 18 20:32:12 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Jan 2017 12:32:12 +1100 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 Message-ID: This change in CMakeLists.txt will cause problems in Visual Studio: --- if( NOT cxx_nullptr IN_LIST CMAKE_CXX11_COMPILE_FEATURES) option(VTK_IGNORE_CXX11_REQUIREMENT OFF) if(NOT VTK_IGNORE_CMAKE_CXX11_CHECKS) message(FATAL_ERROR "VTK now requires a compiler that supports C++11") endif() endif() --- because CMAKE_CXX11_COMPILE_FEATURES is always empty for MSVC compilers. Anyway, if you look at https://msdn.microsoft.com/en-us/library/hh567368.aspx nullptr is probably a bad one to test for with microsoft compilers as it has been supported since VS 2010. Could I suggest using *CMAKE_CXX_COMPILER_ID* and *CMAKE_CXX_COMPILER_VERSION* instead? For example: *message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}")* WIll give you a line like: *The CXX compiler identification is MSVC 19.0.24215.1* It also works with gcc. Regards Andrew > ---------- Forwarded message ---------- > From: Robert Maynard > To: vtk vtk , VTK Developers > Cc: > Date: Wed, 18 Jan 2017 12:11:21 -0500 > Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 > I am happy to announce that over the last two weeks we have rolled out a > series of updates to VTK that mean the minimum required CMake version > is now 3.3 (see below), and now builds with C+11 enabled. > > Yes VTK now requires a C++11 capable compiler. Initial we are only asking > for a > minimal set of C++11 features (nullptr), but as continue forward through > the > year we are going require a larger set of C++11 features. The final exact > versions for each compiler have not been set in stone, but a rough > estimation > would be: > - GCC 4.8+ > - Clang 3.3+ > - XCode 5.0+ > - MSVC 2013+ > > I wanted to send this announcement out to bring up a couple of points: > > 1. Thanks to everyone that has helped get VTK ready for C++11! The final > CMake > switch over to C++11 was very easy, only because of all the hard work that > other > developers did in anticipation of this. So thank you very much. > > 2. The major reason for this slow roll out of C++11 is so that we minimize > the > impact on current VTK merge requests, while also minimizing dashboard > instability. Contributors please be aware of these changes if you have long > running branches. > > 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are > currently > working up a plan on how best to transition these machines to at least GCC > 4.8 > as the roll out continues. > > 4. The current MinGW dashboard machine doesn't support C++11 and will be > removed, with no plan of a replacement at Kitware. If the community is > interested in maintaining a newer MinGW machine I can provide assistance > on how to setup a machine. > > > ============ > > Why CMake 3.3: > > We have chosen CMake 3.3 as the minimum required version for numerous > reasons, > the most important of those reasons being: > > - It is the first CMake release that offers C++11 support for all four > major > compilers ( GCC / MSVC / Clang / XCode ). > > - The CMake version is sufficiently new enough that it allows for a > cleaning > of the existing CMake infrastructure. The current CMake minimum version > requires VTK to maintain forks of numerous FindPackages and Modules that > are > part of newer CMake versions. > > - Supports HTTPS downloads, with all the official binaries come with > support. > Allowing for migration of external data to a HTTPS only server. > Something we > are going to require in the near future. > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jan 18 21:10:06 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 18 Jan 2017 21:10:06 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: Thanks for spotting this, I won't be able to get a fix in before tomorrow morning unfortunately. Sent from my iPhone > On Jan 18, 2017, at 8:32 PM, Andrew Maclean wrote: > > This change in CMakeLists.txt will cause problems in Visual Studio: > --- > if( NOT cxx_nullptr IN_LIST CMAKE_CXX11_COMPILE_FEATURES) > option(VTK_IGNORE_CXX11_REQUIREMENT OFF) > if(NOT VTK_IGNORE_CMAKE_CXX11_CHECKS) > message(FATAL_ERROR "VTK now requires a compiler that supports C++11") > endif() > endif() > --- > because CMAKE_CXX11_COMPILE_FEATURES is always empty for MSVC compilers. > > Anyway, if you look at https://msdn.microsoft.com/en-us/library/hh567368.aspx > nullptr is probably a bad one to test for with microsoft compilers as it has been supported since VS 2010. > > Could I suggest using CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION instead? > > For example: > message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}") > WIll give you a line like: > The CXX compiler identification is MSVC 19.0.24215.1 > It also works with gcc. > > Regards > Andrew > > > > >> >> ---------- Forwarded message ---------- >> From: Robert Maynard >> To: vtk vtk , VTK Developers >> Cc: >> Date: Wed, 18 Jan 2017 12:11:21 -0500 >> Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 >> I am happy to announce that over the last two weeks we have rolled out a >> series of updates to VTK that mean the minimum required CMake version >> is now 3.3 (see below), and now builds with C+11 enabled. >> >> Yes VTK now requires a C++11 capable compiler. Initial we are only asking for a >> minimal set of C++11 features (nullptr), but as continue forward through the >> year we are going require a larger set of C++11 features. The final exact >> versions for each compiler have not been set in stone, but a rough estimation >> would be: >> - GCC 4.8+ >> - Clang 3.3+ >> - XCode 5.0+ >> - MSVC 2013+ >> >> I wanted to send this announcement out to bring up a couple of points: >> >> 1. Thanks to everyone that has helped get VTK ready for C++11! The final CMake >> switch over to C++11 was very easy, only because of all the hard work that other >> developers did in anticipation of this. So thank you very much. >> >> 2. The major reason for this slow roll out of C++11 is so that we minimize the >> impact on current VTK merge requests, while also minimizing dashboard >> instability. Contributors please be aware of these changes if you have long >> running branches. >> >> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are currently >> working up a plan on how best to transition these machines to at least GCC 4.8 >> as the roll out continues. >> >> 4. The current MinGW dashboard machine doesn't support C++11 and will be >> removed, with no plan of a replacement at Kitware. If the community is >> interested in maintaining a newer MinGW machine I can provide assistance >> on how to setup a machine. >> >> >> ============ >> >> Why CMake 3.3: >> >> We have chosen CMake 3.3 as the minimum required version for numerous reasons, >> the most important of those reasons being: >> >> - It is the first CMake release that offers C++11 support for all four major >> compilers ( GCC / MSVC / Clang / XCode ). >> >> - The CMake version is sufficiently new enough that it allows for a cleaning >> of the existing CMake infrastructure. The current CMake minimum version >> requires VTK to maintain forks of numerous FindPackages and Modules that are >> part of newer CMake versions. >> >> - Supports HTTPS downloads, with all the official binaries come with support. >> Allowing for migration of external data to a HTTPS only server. Something we >> are going to require in the near future. >> >> >> > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Jan 18 21:11:59 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Jan 2017 13:11:59 +1100 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: No worries! Andrew Maclean On 19 Jan 2017 13:10, "Robert Maynard" wrote: Thanks for spotting this, I won't be able to get a fix in before tomorrow morning unfortunately. Sent from my iPhone On Jan 18, 2017, at 8:32 PM, Andrew Maclean wrote: This change in CMakeLists.txt will cause problems in Visual Studio: --- if( NOT cxx_nullptr IN_LIST CMAKE_CXX11_COMPILE_FEATURES) option(VTK_IGNORE_CXX11_REQUIREMENT OFF) if(NOT VTK_IGNORE_CMAKE_CXX11_CHECKS) message(FATAL_ERROR "VTK now requires a compiler that supports C++11") endif() endif() --- because CMAKE_CXX11_COMPILE_FEATURES is always empty for MSVC compilers. Anyway, if you look at https://msdn.microsoft.com/ en-us/library/hh567368.aspx nullptr is probably a bad one to test for with microsoft compilers as it has been supported since VS 2010. Could I suggest using *CMAKE_CXX_COMPILER_ID* and *CMAKE_CXX_COMPILER_VERSION* instead? For example: *message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}")* WIll give you a line like: *The CXX compiler identification is MSVC 19.0.24215.1* It also works with gcc. Regards Andrew > ---------- Forwarded message ---------- > From: Robert Maynard > To: vtk vtk , VTK Developers > Cc: > Date: Wed, 18 Jan 2017 12:11:21 -0500 > Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 > I am happy to announce that over the last two weeks we have rolled out a > series of updates to VTK that mean the minimum required CMake version > is now 3.3 (see below), and now builds with C+11 enabled. > > Yes VTK now requires a C++11 capable compiler. Initial we are only asking > for a > minimal set of C++11 features (nullptr), but as continue forward through > the > year we are going require a larger set of C++11 features. The final exact > versions for each compiler have not been set in stone, but a rough > estimation > would be: > - GCC 4.8+ > - Clang 3.3+ > - XCode 5.0+ > - MSVC 2013+ > > I wanted to send this announcement out to bring up a couple of points: > > 1. Thanks to everyone that has helped get VTK ready for C++11! The final > CMake > switch over to C++11 was very easy, only because of all the hard work that > other > developers did in anticipation of this. So thank you very much. > > 2. The major reason for this slow roll out of C++11 is so that we minimize > the > impact on current VTK merge requests, while also minimizing dashboard > instability. Contributors please be aware of these changes if you have long > running branches. > > 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are > currently > working up a plan on how best to transition these machines to at least GCC > 4.8 > as the roll out continues. > > 4. The current MinGW dashboard machine doesn't support C++11 and will be > removed, with no plan of a replacement at Kitware. If the community is > interested in maintaining a newer MinGW machine I can provide assistance > on how to setup a machine. > > > ============ > > Why CMake 3.3: > > We have chosen CMake 3.3 as the minimum required version for numerous > reasons, > the most important of those reasons being: > > - It is the first CMake release that offers C++11 support for all four > major > compilers ( GCC / MSVC / Clang / XCode ). > > - The CMake version is sufficiently new enough that it allows for a > cleaning > of the existing CMake infrastructure. The current CMake minimum version > requires VTK to maintain forks of numerous FindPackages and Modules that > are > part of newer CMake versions. > > - Supports HTTPS downloads, with all the official binaries come with > support. > Allowing for migration of external data to a HTTPS only server. > Something we > are going to require in the near future. > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Jan 18 23:52:54 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Jan 2017 15:52:54 +1100 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: Actually ... in looking at CMakeLists.txt all you need to do is update the compiler versions in lines 262-295 and you're done! Regards Andrew On Thu, Jan 19, 2017 at 1:11 PM, Andrew Maclean wrote: > No worries! > > Andrew Maclean > > On 19 Jan 2017 13:10, "Robert Maynard" wrote: > > Thanks for spotting this, I won't be able to get a fix in before tomorrow > morning unfortunately. > > Sent from my iPhone > > On Jan 18, 2017, at 8:32 PM, Andrew Maclean > wrote: > > This change in CMakeLists.txt will cause problems in Visual Studio: > --- > if( NOT cxx_nullptr IN_LIST CMAKE_CXX11_COMPILE_FEATURES) > option(VTK_IGNORE_CXX11_REQUIREMENT OFF) > if(NOT VTK_IGNORE_CMAKE_CXX11_CHECKS) > message(FATAL_ERROR "VTK now requires a compiler that supports C++11") > endif() > endif() > --- > because CMAKE_CXX11_COMPILE_FEATURES is always empty for MSVC compilers. > > Anyway, if you look at https://msdn.microsoft.com/ > en-us/library/hh567368.aspx > nullptr is probably a bad one to test for with microsoft compilers as it > has been supported since VS 2010. > > Could I suggest using *CMAKE_CXX_COMPILER_ID* and > *CMAKE_CXX_COMPILER_VERSION* instead? > > For example: > *message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} > ${CMAKE_CXX_COMPILER_VERSION}")* > WIll give you a line like: > *The CXX compiler identification is MSVC 19.0.24215.1* > It also works with gcc. > > Regards > Andrew > > > > > >> ---------- Forwarded message ---------- >> From: Robert Maynard >> To: vtk vtk , VTK Developers >> Cc: >> Date: Wed, 18 Jan 2017 12:11:21 -0500 >> Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 >> I am happy to announce that over the last two weeks we have rolled out a >> series of updates to VTK that mean the minimum required CMake version >> is now 3.3 (see below), and now builds with C+11 enabled. >> >> Yes VTK now requires a C++11 capable compiler. Initial we are only asking >> for a >> minimal set of C++11 features (nullptr), but as continue forward through >> the >> year we are going require a larger set of C++11 features. The final exact >> versions for each compiler have not been set in stone, but a rough >> estimation >> would be: >> - GCC 4.8+ >> - Clang 3.3+ >> - XCode 5.0+ >> - MSVC 2013+ >> >> I wanted to send this announcement out to bring up a couple of points: >> >> 1. Thanks to everyone that has helped get VTK ready for C++11! The final >> CMake >> switch over to C++11 was very easy, only because of all the hard work >> that other >> developers did in anticipation of this. So thank you very much. >> >> 2. The major reason for this slow roll out of C++11 is so that we >> minimize the >> impact on current VTK merge requests, while also minimizing dashboard >> instability. Contributors please be aware of these changes if you have >> long >> running branches. >> >> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are >> currently >> working up a plan on how best to transition these machines to at least >> GCC 4.8 >> as the roll out continues. >> >> 4. The current MinGW dashboard machine doesn't support C++11 and will be >> removed, with no plan of a replacement at Kitware. If the community is >> interested in maintaining a newer MinGW machine I can provide assistance >> on how to setup a machine. >> >> >> ============ >> >> Why CMake 3.3: >> >> We have chosen CMake 3.3 as the minimum required version for numerous >> reasons, >> the most important of those reasons being: >> >> - It is the first CMake release that offers C++11 support for all four >> major >> compilers ( GCC / MSVC / Clang / XCode ). >> >> - The CMake version is sufficiently new enough that it allows for a >> cleaning >> of the existing CMake infrastructure. The current CMake minimum version >> requires VTK to maintain forks of numerous FindPackages and Modules >> that are >> part of newer CMake versions. >> >> - Supports HTTPS downloads, with all the official binaries come with >> support. >> Allowing for migration of external data to a HTTPS only server. >> Something we >> are going to require in the near future. >> >> >> >> > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Jan 19 00:20:44 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 19 Jan 2017 16:20:44 +1100 Subject: [vtk-developers] VTK and QT5 Message-ID: I see that on the ParaView Developers list that they are moving to Qt5 by default. See Utkarsh's post on Mon 16 Jan 2017, titled: "ParaView and Qt 5". Given that ParaView is built on VTK and that Qt5 is well supported on modern machines. Isn't it time that VTK defaulted to Qt5 also? It seems to me that is a good opportunity to do this now that VTK has moved to C++11. >From reading this: https://woboq.com/blog/cpp11-in-qt5.html it shouldn't affect those still using Qt 4.8. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Jan 19 09:02:22 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 19 Jan 2017 09:02:22 -0500 Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: That does look like the perfect way to resolve this. On Wed, Jan 18, 2017 at 11:52 PM, Andrew Maclean wrote: > Actually ... in looking at CMakeLists.txt all you need to do is update the > compiler versions in lines 262-295 and you're done! > > Regards > Andrew > > On Thu, Jan 19, 2017 at 1:11 PM, Andrew Maclean > wrote: >> >> No worries! >> >> Andrew Maclean >> >> On 19 Jan 2017 13:10, "Robert Maynard" wrote: >> >> Thanks for spotting this, I won't be able to get a fix in before tomorrow >> morning unfortunately. >> >> Sent from my iPhone >> >> On Jan 18, 2017, at 8:32 PM, Andrew Maclean >> wrote: >> >> This change in CMakeLists.txt will cause problems in Visual Studio: >> --- >> if( NOT cxx_nullptr IN_LIST CMAKE_CXX11_COMPILE_FEATURES) >> option(VTK_IGNORE_CXX11_REQUIREMENT OFF) >> if(NOT VTK_IGNORE_CMAKE_CXX11_CHECKS) >> message(FATAL_ERROR "VTK now requires a compiler that supports C++11") >> endif() >> endif() >> --- >> because CMAKE_CXX11_COMPILE_FEATURES is always empty for MSVC compilers. >> >> Anyway, if you look at >> https://msdn.microsoft.com/en-us/library/hh567368.aspx >> nullptr is probably a bad one to test for with microsoft compilers as it >> has been supported since VS 2010. >> >> Could I suggest using CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION >> instead? >> >> For example: >> message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} >> ${CMAKE_CXX_COMPILER_VERSION}") >> WIll give you a line like: >> The CXX compiler identification is MSVC 19.0.24215.1 >> It also works with gcc. >> >> Regards >> Andrew >> >> >> >> >>> >>> ---------- Forwarded message ---------- >>> From: Robert Maynard >>> To: vtk vtk , VTK Developers >>> Cc: >>> Date: Wed, 18 Jan 2017 12:11:21 -0500 >>> Subject: [vtk-developers] VTK updated to CMake 3.3 and C++11 >>> I am happy to announce that over the last two weeks we have rolled out a >>> series of updates to VTK that mean the minimum required CMake version >>> is now 3.3 (see below), and now builds with C+11 enabled. >>> >>> Yes VTK now requires a C++11 capable compiler. Initial we are only asking >>> for a >>> minimal set of C++11 features (nullptr), but as continue forward through >>> the >>> year we are going require a larger set of C++11 features. The final exact >>> versions for each compiler have not been set in stone, but a rough >>> estimation >>> would be: >>> - GCC 4.8+ >>> - Clang 3.3+ >>> - XCode 5.0+ >>> - MSVC 2013+ >>> >>> I wanted to send this announcement out to bring up a couple of points: >>> >>> 1. Thanks to everyone that has helped get VTK ready for C++11! The final >>> CMake >>> switch over to C++11 was very easy, only because of all the hard work >>> that other >>> developers did in anticipation of this. So thank you very much. >>> >>> 2. The major reason for this slow roll out of C++11 is so that we >>> minimize the >>> impact on current VTK merge requests, while also minimizing dashboard >>> instability. Contributors please be aware of these changes if you have >>> long >>> running branches. >>> >>> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are >>> currently >>> working up a plan on how best to transition these machines to at least >>> GCC 4.8 >>> as the roll out continues. >>> >>> 4. The current MinGW dashboard machine doesn't support C++11 and will be >>> removed, with no plan of a replacement at Kitware. If the community is >>> interested in maintaining a newer MinGW machine I can provide assistance >>> on how to setup a machine. >>> >>> >>> ============ >>> >>> Why CMake 3.3: >>> >>> We have chosen CMake 3.3 as the minimum required version for numerous >>> reasons, >>> the most important of those reasons being: >>> >>> - It is the first CMake release that offers C++11 support for all four >>> major >>> compilers ( GCC / MSVC / Clang / XCode ). >>> >>> - The CMake version is sufficiently new enough that it allows for a >>> cleaning >>> of the existing CMake infrastructure. The current CMake minimum version >>> requires VTK to maintain forks of numerous FindPackages and Modules >>> that are >>> part of newer CMake versions. >>> >>> - Supports HTTPS downloads, with all the official binaries come with >>> support. >>> Allowing for migration of external data to a HTTPS only server. >>> Something we >>> are going to require in the near future. >>> >>> >>> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ From marcus.hanwell at kitware.com Thu Jan 19 09:43:12 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 19 Jan 2017 09:43:12 -0500 Subject: [vtk-developers] VTK and QT5 In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 12:20 AM, Andrew Maclean wrote: > I see that on the ParaView Developers list that they are moving to Qt5 by > default. See Utkarsh's post on Mon 16 Jan 2017, titled: "ParaView and Qt 5". > > Given that ParaView is built on VTK and that Qt5 is well supported on modern > machines. Isn't it time that VTK defaulted to Qt5 also? > > It seems to me that is a good opportunity to do this now that VTK has moved > to C++11. > I totally agree, and have been wanting to move VTK forward for a while. One of the big blockers was the QVTKWidget (and its sequel), but the new QVTKOpenGLWidget fixes those issues. We are looking for any remaining issues, and I think need to require at least Qt 5.5 for some fixes to the way events are squashed (need to check as my memory is hazy on what release they got in). From gpwright at gmail.com Thu Jan 19 10:08:06 2017 From: gpwright at gmail.com (Geoff Wright) Date: Thu, 19 Jan 2017 15:08:06 +0000 Subject: [vtk-developers] VTK and QT5 In-Reply-To: References: Message-ID: Hi all, While moving VTK onto Qt 5 by default, it would be great to consider integration with QQuickFramebufferObject so that it can be easily used in a modern Qml application. This approach has several advantages. It can allow for multi-threaded OpenGL with several VTK pipelines each linked to a different QML Item and each refreshing on its own thread, to textures that are then drawn on the "qml thread" (which is different from the Qt main thread). This can allow for very flexible use of VTK in high performance real time applications. I've been using VTK via this approach for several years with Qt 5.6 in an application where the UI is written in Qml rather than C++. I haven't been able to submit these changes back to VTK but the approach I'm using is the same as what is described here: https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6 If anyone is interested in integrating this into VTK I would be happy to provide further info. My codebase is sadly not open source licensed but I can describe the approach I'm using in more detail. Regards, Geoff On Thu, Jan 19, 2017 at 9:43 AM Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > On Thu, Jan 19, 2017 at 12:20 AM, Andrew Maclean > wrote: > > I see that on the ParaView Developers list that they are moving to Qt5 by > > default. See Utkarsh's post on Mon 16 Jan 2017, titled: "ParaView and Qt > 5". > > > > Given that ParaView is built on VTK and that Qt5 is well supported on > modern > > machines. Isn't it time that VTK defaulted to Qt5 also? > > > > It seems to me that is a good opportunity to do this now that VTK has > moved > > to C++11. > > > I totally agree, and have been wanting to move VTK forward for a > while. One of the big blockers was the QVTKWidget (and its sequel), > but the new QVTKOpenGLWidget fixes those issues. We are looking for > any remaining issues, and I think need to require at least Qt 5.5 for > some fixes to the way events are squashed (need to check as my memory > is hazy on what release they got in). > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Jan 19 10:33:52 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 19 Jan 2017 10:33:52 -0500 Subject: [vtk-developers] VTK and QT5 In-Reply-To: References: Message-ID: +1. One little caveat, I have only added support for the new QVTKOpenGLWidget for OpenGL2 backend. While it may be possible to use it with OpenGL1 backend it will need more testing and debugging. There was a lot of rendering code that made assumptions about active frame buffer that didn't work with QVTKOpenGLWidget that needed fixing. I don't think this should be a hurdle in moving to Qt 5, but thought I'd mention. So far, the QVTKOpenGLWidget has been working well for ParaView. We got Windows and Linux dashboards clean and green. We'll soon be adding OsX dashboards too (need some unrelated fixes before that can happen). Utkarsh On Thu, Jan 19, 2017 at 9:43 AM, Marcus D. Hanwell wrote: > On Thu, Jan 19, 2017 at 12:20 AM, Andrew Maclean > wrote: >> I see that on the ParaView Developers list that they are moving to Qt5 by >> default. See Utkarsh's post on Mon 16 Jan 2017, titled: "ParaView and Qt 5". >> >> Given that ParaView is built on VTK and that Qt5 is well supported on modern >> machines. Isn't it time that VTK defaulted to Qt5 also? >> >> It seems to me that is a good opportunity to do this now that VTK has moved >> to C++11. >> > I totally agree, and have been wanting to move VTK forward for a > while. One of the big blockers was the QVTKWidget (and its sequel), > but the new QVTKOpenGLWidget fixes those issues. We are looking for > any remaining issues, and I think need to require at least Qt 5.5 for > some fixes to the way events are squashed (need to check as my memory > is hazy on what release they got in). > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From marcus.hanwell at kitware.com Thu Jan 19 10:46:04 2017 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 19 Jan 2017 10:46:04 -0500 Subject: [vtk-developers] VTK and QT5 In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 10:08 AM, Geoff Wright wrote: > Hi all, > > While moving VTK onto Qt 5 by default, it would be great to consider > integration with QQuickFramebufferObject so that it can be easily used in a > modern Qml application. This approach has several advantages. It can allow > for multi-threaded OpenGL with several VTK pipelines each linked to a > different QML Item and each refreshing on its own thread, to textures that > are then drawn on the "qml thread" (which is different from the Qt main > thread). This can allow for very flexible use of VTK in high performance > real time applications. > > I've been using VTK via this approach for several years with Qt 5.6 in an > application where the UI is written in Qml rather than C++. I haven't been > able to submit these changes back to VTK but the approach I'm using is the > same as what is described here: > https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6 > > If anyone is interested in integrating this into VTK I would be happy to > provide further info. My codebase is sadly not open source licensed but I > can describe the approach I'm using in more detail. > That sounds nice, I wouldn't tie our move to Qt 5 as the default to adding support for this, but it would be a great addition. I don't have any current work with QML, but if anyone was interested in working on this I would try to help with reviews and testing. The QVTKWidget2 attempted some integration with QML as I remember it, but it does not work with Qt 5. Thanks for the link to the gist. From elvis.stansvik at orexplore.com Thu Jan 19 10:56:25 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 19 Jan 2017 16:56:25 +0100 Subject: [vtk-developers] VTK and QT5 In-Reply-To: References: Message-ID: 2017-01-19 15:43 GMT+01:00 Marcus D. Hanwell : > On Thu, Jan 19, 2017 at 12:20 AM, Andrew Maclean > wrote: > > I see that on the ParaView Developers list that they are moving to Qt5 by > > default. See Utkarsh's post on Mon 16 Jan 2017, titled: "ParaView and Qt > 5". > > > > Given that ParaView is built on VTK and that Qt5 is well supported on > modern > > machines. Isn't it time that VTK defaulted to Qt5 also? > > > > It seems to me that is a good opportunity to do this now that VTK has > moved > > to C++11. > > > I totally agree, and have been wanting to move VTK forward for a > while. One of the big blockers was the QVTKWidget (and its sequel), > but the new QVTKOpenGLWidget fixes those issues. We are looking for > any remaining issues, and I think need to require at least Qt 5.5 for > some fixes to the way events are squashed (need to check as my memory > is hazy on what release they got in). > I'm afraid that fix was abandoned for 5.5 and only landed in 5.6 :/ I'm working around it in my QVTKWidget subclass by letting Qt be the one in charge of when Render() is called. It would be great if some workaround could be made in VTK, such that the requirement wouldn't have to be bumped all the way to 5.6, since it's not in official repos for LTS distros like Ubuntu 16.04. Elvis _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Jan 19 11:19:28 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Jan 2017 11:19:28 -0500 Subject: [vtk-developers] CDash links from buildbot Message-ID: <20170119161928.GA26876@megas.kitware.com> Hi, I recently changed the CDash link that buildbot constructs to be based on the revision rather than the name of the build and an "after" filter. However, it turns out CDash that has an implicit "today" filter in there which causes the results shown to change over time. After talking with Zack about it, a plain revision query shouldn't have an implicit date range associated with it, so once the fix is deployed (hopefully today), the links will work again as intended. Until then, you can add a "Build Start Time" "is before" "now" filter to get all of the builds. Sorry for the disruption, --Ben From ben.boeckel at kitware.com Thu Jan 19 11:43:53 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 19 Jan 2017 11:43:53 -0500 Subject: [vtk-developers] CDash links from buildbot In-Reply-To: <20170119161928.GA26876@megas.kitware.com> References: <20170119161928.GA26876@megas.kitware.com> Message-ID: <20170119164353.GA6446@megas.kitware.com> On Thu, Jan 19, 2017 at 11:19:28 -0500, Ben Boeckel wrote: > range associated with it, so once the fix is deployed (hopefully today), > the links will work again as intended. Zack says the fix has been deployed. --Ben From robert.maynard at kitware.com Thu Jan 19 14:15:22 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 19 Jan 2017 14:15:22 -0500 Subject: [vtk-developers] [vtkusers] VTK updated to CMake 3.3 and C++11 In-Reply-To: References: Message-ID: Hi Carlos, A regression to the build system was merged in last night that broke building with Visual Studio. A correction was just ( 15 minutes ago ) merged into VTK master that restores building with Visual Studio. Sorry for the inconvenience. On Thu, Jan 19, 2017 at 2:07 PM, Carlos Lopez wrote: > Hi, > > The C++11 check is failing for me. I'm using CMAKE 3.6.2 on windows with > Visual studio Community 15. > > Removing the check within cmake allows me to build without issues. > > I'm building from gitlab's main repo, updated today. > > best, > carlos > > > > On Wed, Jan 18, 2017 at 12:11 PM, Robert Maynard > wrote: >> >> I am happy to announce that over the last two weeks we have rolled out a >> series of updates to VTK that mean the minimum required CMake version >> is now 3.3 (see below), and now builds with C+11 enabled. >> >> Yes VTK now requires a C++11 capable compiler. Initial we are only asking >> for a >> minimal set of C++11 features (nullptr), but as continue forward through >> the >> year we are going require a larger set of C++11 features. The final exact >> versions for each compiler have not been set in stone, but a rough >> estimation >> would be: >> - GCC 4.8+ >> - Clang 3.3+ >> - XCode 5.0+ >> - MSVC 2013+ >> >> I wanted to send this announcement out to bring up a couple of points: >> >> 1. Thanks to everyone that has helped get VTK ready for C++11! The final >> CMake >> switch over to C++11 was very easy, only because of all the hard work that >> other >> developers did in anticipation of this. So thank you very much. >> >> 2. The major reason for this slow roll out of C++11 is so that we minimize >> the >> impact on current VTK merge requests, while also minimizing dashboard >> instability. Contributors please be aware of these changes if you have >> long >> running branches. >> >> 3. We currently have dashboard machines running GCC 4.6 & 4.7. We are >> currently >> working up a plan on how best to transition these machines to at least GCC >> 4.8 >> as the roll out continues. >> >> 4. The current MinGW dashboard machine doesn't support C++11 and will be >> removed, with no plan of a replacement at Kitware. If the community is >> interested in maintaining a newer MinGW machine I can provide assistance >> on how to setup a machine. >> >> >> ============ >> >> Why CMake 3.3: >> >> We have chosen CMake 3.3 as the minimum required version for numerous >> reasons, >> the most important of those reasons being: >> >> - It is the first CMake release that offers C++11 support for all four >> major >> compilers ( GCC / MSVC / Clang / XCode ). >> >> - The CMake version is sufficiently new enough that it allows for a >> cleaning >> of the existing CMake infrastructure. The current CMake minimum version >> requires VTK to maintain forks of numerous FindPackages and Modules that >> are >> part of newer CMake versions. >> >> - Supports HTTPS downloads, with all the official binaries come with >> support. >> Allowing for migration of external data to a HTTPS only server. >> Something we >> are going to require in the near future. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Search the list archives at: http://markmail.org/search/?q=vtkusers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers > > From sean at rogue-research.com Thu Jan 19 22:13:24 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 19 Jan 2017 22:13:24 -0500 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings Message-ID: <20170120031324.934419583@mail.rogue-research.com> Hi all, I've deliberately un-suppressed cppcheck's duplInheritedMember warning and now we have 24 warnings here: The warning is telling us that various classes have ivars with the same name as an ivar in their superclass. This is a pretty bad code smell IMNSHO. But it takes someone who knows the classes well to decide on the best fix... The warnings are: Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines member variable with name 'Colors' also defined in its parent class 'vtkPlot3D'. Charts/Core/vtkChartMatrix.h:155: warning: The class 'vtkScatterPlotMatrix' defines member variable with name 'Private' also defined in its parent class 'vtkChartMatrix'. Common/DataModel/vtkPlanes.h:129: warning: The class 'vtkPlanesIntersection' defines member variable with name 'Plane' also defined in its parent class 'vtkPlanes'. Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also defined in its parent class 'vtkGenericCellTessellator'. Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: The class 'vtkCompositeDataPipeline' defines member variable with name 'UpdateExtentRequest' also defined in its parent class 'vtkStreamingDemandDrivenPipeline'. Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: The class 'vtkCompositeInterpolatedVelocityField' defines member variable with name 'TOLERANCE_SCALE' also defined in its parent class 'vtkAbstractInterpolatedVelocityField'. IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also defined in its parent class 'vtkTableToDatabaseWriter'. Imaging/Core/vtkImageReslice.h:510: warning: The class 'vtkImageResample' defines member variable with name 'OutputSpacing' also defined in its parent class 'vtkImageReslice'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'Modifier' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P1World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P2World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P3World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P4World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P21World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'P43World' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'T21' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'T43' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'CenterWorld' also defined in its parent class 'vtkBiDimensionalRepresentation'. Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The class 'vtkBiDimensionalRepresentation2D' defines member variable with name 'StartEventPositionWorld' also defined in its parent class 'vtkBiDimensionalRepresentation'. Rendering/Core/vtkColorTransferFunction.h:398: warning: The class 'vtkDiscretizableColorTransferFunction' defines member variable with name 'BuildTime' also defined in its parent class 'vtkColorTransferFunction'. Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class 'vtkHardwareSelectionPolyDataPainter' defines member variable with name 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class 'vtkXRenderWindowTclInteractor' defines member variable with name 'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. Views/Infovis/vtkRenderView.h:289: warning: The class 'vtkGraphLayoutView' defines member variable with name 'Interacting' also defined in its parent class 'vtkRenderView'. Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class 'vtkRenderedTreeAreaRepresentation' defines member variable with name 'Implementation' also defined in its parent class 'vtkRenderedRepresentation'. From sur.chiranjib at gmail.com Fri Jan 20 02:27:16 2017 From: sur.chiranjib at gmail.com (Chiranjib Sur) Date: Fri, 20 Jan 2017 12:57:16 +0530 Subject: [vtk-developers] vtk - PointInsideObject - is the problem is due to precision? Message-ID: Hi All, I am trying to extend the example to find points inside an object ( http://www.vtk.org/Wiki/VTK/Examples/Cxx/PolyData/PointInsideObject). The idea is to fill a 3D volume with points inside it. While doing so, I am finding that for some points which are actually outside the object are getting detected as inside. To picture on the left is my original object and on the right is the object filled with points [image: Inline image 1] [image: Inline image 2] You will find that few points which are actually outside are getting detected as inside. Any idea what is happening? The object file and the source codes are attached. Thanks, Chiranjib -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 20931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 314490 bytes Desc: not available URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8) PROJECT(FillObject) set( CMAKE_CXX_FLAGS "-g") find_package(VTK REQUIRED) find_package(Qt5Widgets) find_package(Qt5Core) find_package(Qt5Designer) include(${VTK_USE_FILE}) add_executable(FillObject MACOSX_BUNDLE FillObject) if(VTK_LIBRARIES) target_link_libraries(FillObject ${VTK_LIBRARIES} Qt5::Widgets Qt5::Core) else() target_link_libraries(FillObject vtkHybrid vtkWidgets Qt5::Widgets Qt5::Core) endif() -------------- next part -------------- A non-text attachment was scrubbed... Name: FillObject.cpp Type: text/x-c++src Size: 3478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Groove_cylinder.stl Type: application/octet-stream Size: 52384 bytes Desc: not available URL: From andy.bauer at kitware.com Fri Jan 20 10:21:01 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 20 Jan 2017 10:21:01 -0500 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: <20170120031324.934419583@mail.rogue-research.com> References: <20170120031324.934419583@mail.rogue-research.com> Message-ID: Hi Sean, Thanks for looking at this. I'll take a look at Filters/FlowPaths/ vtkAbstractInterpolatedVelocityField.h. Best, Andy On Thu, Jan 19, 2017 at 10:13 PM, Sean McBride wrote: > Hi all, > > I've deliberately un-suppressed cppcheck's duplInheritedMember warning and > now we have 24 warnings here: > > > > The warning is telling us that various classes have ivars with the same > name as an ivar in their superclass. This is a pretty bad code smell IMNSHO. > > But it takes someone who knows the classes well to decide on the best > fix... > > The warnings are: > > Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines > member variable with name 'Colors' also defined in its parent class > 'vtkPlot3D'. > > Charts/Core/vtkChartMatrix.h:155: warning: The class > 'vtkScatterPlotMatrix' defines member variable with name 'Private' also > defined in its parent class 'vtkChartMatrix'. > > Common/DataModel/vtkPlanes.h:129: warning: The class > 'vtkPlanesIntersection' defines member variable with name 'Plane' also > defined in its parent class 'vtkPlanes'. > > Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class > 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also > defined in its parent class 'vtkGenericCellTessellator'. > > Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: > The class 'vtkCompositeDataPipeline' defines member variable with name > 'UpdateExtentRequest' also defined in its parent class ' > vtkStreamingDemandDrivenPipeline'. > > Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: > The class 'vtkCompositeInterpolatedVelocityField' defines member variable > with name 'TOLERANCE_SCALE' also defined in its parent class ' > vtkAbstractInterpolatedVelocityField'. > > IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class > 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also > defined in its parent class 'vtkTableToDatabaseWriter'. > > Imaging/Core/vtkImageReslice.h:510: warning: The class 'vtkImageResample' > defines member variable with name 'OutputSpacing' also defined in its > parent class 'vtkImageReslice'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'Modifier' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P1World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P2World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P3World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P4World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P21World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'P43World' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'T21' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'T43' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'CenterWorld' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The > class 'vtkBiDimensionalRepresentation2D' defines member variable with > name 'StartEventPositionWorld' also defined in its parent class ' > vtkBiDimensionalRepresentation'. > > Rendering/Core/vtkColorTransferFunction.h:398: warning: The class ' > vtkDiscretizableColorTransferFunction' defines member variable with name > 'BuildTime' also defined in its parent class 'vtkColorTransferFunction'. > > Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class ' > vtkHardwareSelectionPolyDataPainter' defines member variable with name > 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. > > Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class 'vtkXRenderWindowTclInteractor' > defines member variable with name 'Internal' also defined in its parent > class 'vtkXRenderWindowInteractor'. > > Views/Infovis/vtkRenderView.h:289: warning: The class > 'vtkGraphLayoutView' defines member variable with name 'Interacting' also > defined in its parent class 'vtkRenderView'. > > Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class ' > vtkRenderedTreeAreaRepresentation' defines member variable with name > 'Implementation' also defined in its parent class > 'vtkRenderedRepresentation'. > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.bauer at kitware.com Fri Jan 20 10:35:49 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 20 Jan 2017 10:35:49 -0500 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> Message-ID: Ha, mine was easy! A static const member variable with identical values :) MR at https://gitlab.kitware.com/vtk/vtk/merge_requests/2407. On Fri, Jan 20, 2017 at 10:21 AM, Andy Bauer wrote: > Hi Sean, > > Thanks for looking at this. I'll take a look at > Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h. > > Best, > Andy > > On Thu, Jan 19, 2017 at 10:13 PM, Sean McBride > wrote: > >> Hi all, >> >> I've deliberately un-suppressed cppcheck's duplInheritedMember warning >> and now we have 24 warnings here: >> >> >> >> The warning is telling us that various classes have ivars with the same >> name as an ivar in their superclass. This is a pretty bad code smell IMNSHO. >> >> But it takes someone who knows the classes well to decide on the best >> fix... >> >> The warnings are: >> >> Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines >> member variable with name 'Colors' also defined in its parent class >> 'vtkPlot3D'. >> >> Charts/Core/vtkChartMatrix.h:155: warning: The class >> 'vtkScatterPlotMatrix' defines member variable with name 'Private' also >> defined in its parent class 'vtkChartMatrix'. >> >> Common/DataModel/vtkPlanes.h:129: warning: The class >> 'vtkPlanesIntersection' defines member variable with name 'Plane' also >> defined in its parent class 'vtkPlanes'. >> >> Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class >> 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also >> defined in its parent class 'vtkGenericCellTessellator'. >> >> Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: >> The class 'vtkCompositeDataPipeline' defines member variable with name >> 'UpdateExtentRequest' also defined in its parent class >> 'vtkStreamingDemandDrivenPipeline'. >> >> Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: >> The class 'vtkCompositeInterpolatedVelocityField' defines member >> variable with name 'TOLERANCE_SCALE' also defined in its parent class >> 'vtkAbstractInterpolatedVelocityField'. >> >> IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class >> 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also >> defined in its parent class 'vtkTableToDatabaseWriter'. >> >> Imaging/Core/vtkImageReslice.h:510: warning: The class >> 'vtkImageResample' defines member variable with name 'OutputSpacing' also >> defined in its parent class 'vtkImageReslice'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'Modifier' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P1World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P2World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P3World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P4World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P21World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'P43World' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'T21' also defined in its parent class 'vtkBiDimensionalRepresentatio >> n'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'T43' also defined in its parent class 'vtkBiDimensionalRepresentatio >> n'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'CenterWorld' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The >> class 'vtkBiDimensionalRepresentation2D' defines member variable with >> name 'StartEventPositionWorld' also defined in its parent class >> 'vtkBiDimensionalRepresentation'. >> >> Rendering/Core/vtkColorTransferFunction.h:398: warning: The class >> 'vtkDiscretizableColorTransferFunction' defines member variable with >> name 'BuildTime' also defined in its parent class >> 'vtkColorTransferFunction'. >> >> Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class >> 'vtkHardwareSelectionPolyDataPainter' defines member variable with name >> 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. >> >> Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class >> 'vtkXRenderWindowTclInteractor' defines member variable with name >> 'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. >> >> Views/Infovis/vtkRenderView.h:289: warning: The class >> 'vtkGraphLayoutView' defines member variable with name 'Interacting' also >> defined in its parent class 'vtkRenderView'. >> >> Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class >> 'vtkRenderedTreeAreaRepresentation' defines member variable with name >> 'Implementation' also defined in its parent class >> 'vtkRenderedRepresentation'. >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Jan 20 13:31:47 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 20 Jan 2017 11:31:47 -0700 Subject: [vtk-developers] help with cppcheck duplInheritedMember warnings In-Reply-To: References: <20170120031324.934419583@mail.rogue-research.com> Message-ID: I've fixed the dupes in vtkPlanesIntersection and vtkImageResample. The latter was nasty. https://gitlab.kitware.com/vtk/vtk/merge_requests/2409 - David On Fri, Jan 20, 2017 at 8:35 AM, Andy Bauer wrote: > Ha, mine was easy! A static const member variable with identical values :) > > MR at https://gitlab.kitware.com/vtk/vtk/merge_requests/2407. > > On Fri, Jan 20, 2017 at 10:21 AM, Andy Bauer > wrote: > >> Hi Sean, >> >> Thanks for looking at this. I'll take a look at >> Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h. >> >> Best, >> Andy >> >> On Thu, Jan 19, 2017 at 10:13 PM, Sean McBride >> wrote: >> >>> Hi all, >>> >>> I've deliberately un-suppressed cppcheck's duplInheritedMember warning >>> and now we have 24 warnings here: >>> >>> >>> >>> The warning is telling us that various classes have ivars with the same >>> name as an ivar in their superclass. This is a pretty bad code smell IMNSHO. >>> >>> But it takes someone who knows the classes well to decide on the best >>> fix... >>> >>> The warnings are: >>> >>> Charts/Core/vtkPlot3D.h:152: warning: The class 'vtkPlotSurface' defines >>> member variable with name 'Colors' also defined in its parent class >>> 'vtkPlot3D'. >>> >>> Charts/Core/vtkChartMatrix.h:155: warning: The class >>> 'vtkScatterPlotMatrix' defines member variable with name 'Private' also >>> defined in its parent class 'vtkChartMatrix'. >>> >>> Common/DataModel/vtkPlanes.h:129: warning: The class >>> 'vtkPlanesIntersection' defines member variable with name 'Plane' also >>> defined in its parent class 'vtkPlanes'. >>> >>> Common/DataModel/vtkGenericCellTessellator.h:211: warning: The class >>> 'vtkSimpleCellTessellator' defines member variable with name 'DataSet' also >>> defined in its parent class 'vtkGenericCellTessellator'. >>> >>> Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.h:349: warning: >>> The class 'vtkCompositeDataPipeline' defines member variable with name >>> 'UpdateExtentRequest' also defined in its parent class >>> 'vtkStreamingDemandDrivenPipeline'. >>> >>> Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.h:211: warning: >>> The class 'vtkCompositeInterpolatedVelocityField' defines member >>> variable with name 'TOLERANCE_SCALE' also defined in its parent class >>> 'vtkAbstractInterpolatedVelocityField'. >>> >>> IO/SQL/vtkTableToDatabaseWriter.h:75: warning: The class >>> 'vtkTableToSQLiteWriter' defines member variable with name 'Input' also >>> defined in its parent class 'vtkTableToDatabaseWriter'. >>> >>> Imaging/Core/vtkImageReslice.h:510: warning: The class >>> 'vtkImageResample' defines member variable with name 'OutputSpacing' also >>> defined in its parent class 'vtkImageReslice'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:213: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'Modifier' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:233: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P1World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:234: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P2World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:235: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P3World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:236: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P4World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:237: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P21World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:238: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'P43World' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:239: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'T21' also defined in its parent class 'vtkBiDimensionalRepresentatio >>> n'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:240: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'T43' also defined in its parent class 'vtkBiDimensionalRepresentatio >>> n'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:241: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'CenterWorld' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Interaction/Widgets/vtkBiDimensionalRepresentation.h:242: warning: The >>> class 'vtkBiDimensionalRepresentation2D' defines member variable with >>> name 'StartEventPositionWorld' also defined in its parent class >>> 'vtkBiDimensionalRepresentation'. >>> >>> Rendering/Core/vtkColorTransferFunction.h:398: warning: The class >>> 'vtkDiscretizableColorTransferFunction' defines member variable with >>> name 'BuildTime' also defined in its parent class >>> 'vtkColorTransferFunction'. >>> >>> Rendering/OpenGL/vtkStandardPolyDataPainter.h:86: warning: The class >>> 'vtkHardwareSelectionPolyDataPainter' defines member variable with name >>> 'TotalCells' also defined in its parent class 'vtkStandardPolyDataPainter'. >>> >>> Rendering/OpenGL/vtkXRenderWindowInteractor.h:198: warning: The class >>> 'vtkXRenderWindowTclInteractor' defines member variable with name >>> 'Internal' also defined in its parent class 'vtkXRenderWindowInteractor'. >>> >>> Views/Infovis/vtkRenderView.h:289: warning: The class >>> 'vtkGraphLayoutView' defines member variable with name 'Interacting' also >>> defined in its parent class 'vtkRenderView'. >>> >>> Views/Infovis/vtkRenderedRepresentation.h:96: warning: The class >>> 'vtkRenderedTreeAreaRepresentation' defines member variable with name >>> 'Implementation' also defined in its parent class >>> 'vtkRenderedRepresentation'. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Fri Jan 20 13:41:24 2017 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 20 Jan 2017 14:41:24 -0400 Subject: [vtk-developers] ANN: VTK & ParaView Training Course in Lyon, France, March 14-15, 2017 Message-ID: Kitware will be holding 2 days of courses on VTK and ParaView on March 14-15, 2017 in Lyon, France. Please visit our web site for more information and registration details at either: VTK: http://training.kitware.fr/browse/144 ParaView: http://training.kitware.fr/browse/145 Note that the courses will be taught in English. If you have any question, please contact us at formations at http://www.kitware.eu Thank you, *Joachim Pouderoux*, PhD *Technical Expert - Scientific Computing Team* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Jan 20 16:19:37 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 20 Jan 2017 16:19:37 -0500 Subject: [vtk-developers] OpenGLVertexBufferObject fails to compile with clang3.0 Message-ID: After updating today, OpenGLVertexBufferObject fails to compile on clang3.0. Here is a MR to fix the problem: https://gitlab.kitware.com/vtk/vtk/merge_requests/2412 Bill -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Mon Jan 23 07:17:47 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 23 Jan 2017 07:17:47 -0500 Subject: [vtk-developers] google summer of code 2017? Message-ID: Hey Gang, Who's excited to be a GSoC mentor this summer? GSoC is a great program that trains new developers by pairing them with experienced mentors immersed in open source projects like VTK. In the past we've gotten some good contributions out of the students, including chemistry work, threaded image filter improvements, and vtk-m algorithms to name a few. The only drawback is that mentoring, when done right, is a significant effort. As such I'm looking for volunteers first that are excited to mentor this summer and are able to commit to finding the time for it. Those volunteers will have to dream up compelling ideas (better than last years or VTK won't be accepted into the program) that will attract and maintain student interest throughout the summer. Please let me know if you are willing this year. If we get enough interest I'll put our application together. thanks! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Jan 24 09:57:11 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 24 Jan 2017 09:57:11 -0500 Subject: [vtk-developers] ANN: Point Cloud Wiki Examples Message-ID: Folks, Will Schroeder has added a number of new filters to process point clouds. These are exciting additions to VTK. We have added number of new wiki examples that illustrate some of the new point cloud filters: Surface extraction http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/ExtractSurface Extract clusters http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/ExtractCluster Estimate normals http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/NormalEstimation Select points near an implicit function http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/FitImplicitFunction Add points to a point cloud http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/DensifyPoints Compute signed and unsigned distances to a point cloud http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/SignedDistance http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/UnsignedDistance Enjoy, Bill -- Unpaid intern in BillsBasement at noware dot com From andrew.amaclean at gmail.com Tue Jan 24 16:39:01 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 25 Jan 2017 08:39:01 +1100 Subject: [vtk-developers] ANN: Point Cloud Wiki Examples Message-ID: These are excellent examples ... +3! They demonstrate the use of the point cloud filters really well. Andrew ---------- Forwarded message ---------- > From: Bill Lorensen > To: VTK Developers , VTK Users > Cc: > Date: Tue, 24 Jan 2017 09:57:11 -0500 > Subject: [vtk-developers] ANN: Point Cloud Wiki Examples > Folks, > > Will Schroeder has added a number of new filters to process point > clouds. These are exciting additions to VTK. > > We have added number of new wiki examples that illustrate some of the > new point cloud filters: > > Surface extraction > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/ExtractSurface > > Extract clusters http://www.vtk.org/Wiki/VTK/Ex > amples/Cxx/Points/ExtractCluster > > Estimate normals > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/NormalEstimation > > Select points near an implicit function > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/FitImplicitFunction > > Add points to a point cloud > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/DensifyPoints > > Compute signed and unsigned distances to a point cloud > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/SignedDistance > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Points/UnsignedDistance > > Enjoy, > > Bill > > > > -- > Unpaid intern in BillsBasement at noware dot com > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorge.vigil at civilnova.com Thu Jan 26 09:57:29 2017 From: jorge.vigil at civilnova.com (Jorge Vigil) Date: Thu, 26 Jan 2017 15:57:29 +0100 Subject: [vtk-developers] Runtime crash using VTK statically linked Message-ID: Hi, We're facing some runtime crashes using Vtk static library. Our configuration is: vtk version: 7.1.0 OS: Windows 10 64 bit Compiler: msvc 2015 update 2 CMAKE flags: CMAKE_CXX_FLAGS_DEBUG = "/D_DEBUG /MDd /Zi /Od" BUILD_SHARED_LIBS = "Off" The callstack always is: ntdll!RtlpBreakPointHeap+0x16 ntdll!RtlpValidateHeapEntry+0x50752 ntdll!RtlValidateHeap+0x9f KERNELBASE!HeapValidate+0xa ucrtbased!CrtIsValidHeapPointer+0x31 ucrtbased!calloc_base+0xa19 ucrtbased!free_dbg+0x55 CN_Graphicsd!odrxFree+0x2e CN_Graphicsd!operator delete[]+0x32 CN_Graphicsd!vtkFieldData::BasicIterator::~BasicIterator+0x30 CN_Graphicsd!vtkDataSetAttributes::ComputeRequiredArrays+0x4ef CN_Graphicsd!vtkDataSetAttributes::PassData+0x59 CN_Graphicsd!vtkTriangleFilter::RequestData+0xc8f CN_Graphicsd!vtkPolyDataAlgorithm::ProcessRequest+0x50 CN_Graphicsd!vtkExecutive::CallAlgorithm+0xa7 CN_Graphicsd!vtkDemandDrivenPipeline::ExecuteData+0x67 CN_Graphicsd!vtkCompositeDataPipeline::ExecuteData+0x414 CN_Graphicsd!vtkDemandDrivenPipeline::ProcessRequest+0x38f CN_Graphicsd!vtkStreamingDemandDrivenPipeline::ProcessRequest+0x8e1 CN_Graphicsd!vtkDemandDrivenPipeline::UpdateData+0x2d9 where CN_Graphics is the name of our internal library. Error output is: HEAP[ProgramName.exe]: Invalid address specified to RtlValidateHeap( 000001A836E40000, 00007FFB9395AE88 ) (4b50.47b8): Break instruction exception - code 80000003 (first chance) We tested the following solution changing the source file vtkFieldData.cxx: **Common/DataModel/vtkFieldData.cxx** : *Line 159* vtkFieldData::BasicIterator::~BasicIterator() { if (this->List && this->ListSize > 0) // <- delete list if and only if it's initialized { delete[] this->List; } this->List = 0; } Curiously, this odd behaviour only occurs when vtk is linked statically. It seem that our proposed solution works fine, but we're not completely sure. Thanks in advance. -- firma_civilnova ------------------------------------------------------------------------ /*Jorge Vigil Iglesias*/ *Ingeniero de Minas* *T:* +34 661973672 *F:* +34 984086393 *E:* jorge.vigil at civilnova.com *W: * www.civilnova.com Logo CivilNova Logo CivilNova *Aviso legal:*Este mensaje y los documentos que, en su caso, lleve anexos, contienen informaci?n privada y confidencial y est? dirigida ?nicamente a su destinatario, seg?n lo dispuesto en la Ley Org?nica 15/99 de Protecci?n de Datos. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha informaci?n por favor elimine el mensaje y comun?quenoslo por la misma v?a. La distribuci?n o copia de este mensaje est? estrictamente prohibida. La transmisi?n de e-mails no garantiza que el correo electr?nico sea seguro o libre de error. Por consiguiente, no manifestamos que esta informaci?n sea completa o precisa. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firma.png Type: image/png Size: 58582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_facebook.png Type: image/png Size: 1877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_twitter.png Type: image/png Size: 2176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_youtube.png Type: image/png Size: 2423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_linkedin.png Type: image/png Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CivilBlastN_black_100.png Type: image/png Size: 49185 bytes Desc: not available URL: From jorge.vigil at civilnova.com Thu Jan 26 09:59:05 2017 From: jorge.vigil at civilnova.com (Jorge Vigil) Date: Thu, 26 Jan 2017 15:59:05 +0100 Subject: [vtk-developers] Runtime crash using VTK statically linked In-Reply-To: References: Message-ID: Hi, We're facing some runtime crashes using Vtk static library. Our configuration is: vtk version: 7.1.0 OS: Windows 10 64 bit Compiler: msvc 2015 update 2 CMAKE flags: CMAKE_CXX_FLAGS_DEBUG = "/D_DEBUG /MDd /Zi /Od" BUILD_SHARED_LIBS = "Off" The callstack always is: ntdll!RtlpBreakPointHeap+0x16 ntdll!RtlpValidateHeapEntry+0x50752 ntdll!RtlValidateHeap+0x9f KERNELBASE!HeapValidate+0xa ucrtbased!CrtIsValidHeapPointer+0x31 ucrtbased!calloc_base+0xa19 ucrtbased!free_dbg+0x55 CN_Graphicsd!odrxFree+0x2e CN_Graphicsd!operator delete[]+0x32 CN_Graphicsd!vtkFieldData::BasicIterator::~BasicIterator+0x30 CN_Graphicsd!vtkDataSetAttributes::ComputeRequiredArrays+0x4ef CN_Graphicsd!vtkDataSetAttributes::PassData+0x59 CN_Graphicsd!vtkTriangleFilter::RequestData+0xc8f CN_Graphicsd!vtkPolyDataAlgorithm::ProcessRequest+0x50 CN_Graphicsd!vtkExecutive::CallAlgorithm+0xa7 CN_Graphicsd!vtkDemandDrivenPipeline::ExecuteData+0x67 CN_Graphicsd!vtkCompositeDataPipeline::ExecuteData+0x414 CN_Graphicsd!vtkDemandDrivenPipeline::ProcessRequest+0x38f CN_Graphicsd!vtkStreamingDemandDrivenPipeline::ProcessRequest+0x8e1 CN_Graphicsd!vtkDemandDrivenPipeline::UpdateData+0x2d9 where CN_Graphics is the name of our internal library. Error output is: HEAP[ProgramName.exe]: Invalid address specified to RtlValidateHeap( 000001A836E40000, 00007FFB9395AE88 ) (4b50.47b8): Break instruction exception - code 80000003 (first chance) We tested the following solution changing the source file vtkFieldData.cxx: **Common/DataModel/vtkFieldData.cxx** : *Line 159* vtkFieldData::BasicIterator::~BasicIterator() { if (this->List && this->ListSize > 0) // <- delete list if and only if it's initialized { delete[] this->List; } this->List = 0; } Curiously, this odd behaviour only occurs when vtk is linked statically. It seem that our proposed solution works fine, but we're not completely sure. Thanks in advance. -- firma_civilnova ------------------------------------------------------------------------ /*Jorge Vigil Iglesias*/ *Ingeniero de Minas* *T:* +34 661973672 *F:* +34 984086393 *E:* jorge.vigil at civilnova.com *W: * www.civilnova.com Logo CivilNova Logo CivilNova *Aviso legal:*Este mensaje y los documentos que, en su caso, lleve anexos, contienen informaci?n privada y confidencial y est? dirigida ?nicamente a su destinatario, seg?n lo dispuesto en la Ley Org?nica 15/99 de Protecci?n de Datos. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha informaci?n por favor elimine el mensaje y comun?quenoslo por la misma v?a. La distribuci?n o copia de este mensaje est? estrictamente prohibida. La transmisi?n de e-mails no garantiza que el correo electr?nico sea seguro o libre de error. Por consiguiente, no manifestamos que esta informaci?n sea completa o precisa. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 58582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2176 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 49185 bytes Desc: not available URL: