From bill.lorensen at gmail.com Tue Aug 1 19:05:26 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 1 Aug 2017 19:05:26 -0400 Subject: [vtk-developers] VTK Developer Trends Message-ID: Folks, There has been a lot of talk lately on the VTK and ITK lists about attracting more developers. Many subjective suggestions are being discussed. >From my GE 6Sigma training, I recall that a more objective approach can be useful. The first step in the process is to measure, then analyze, followed by improve and control. I generated a spreadsheet that tracks the number of developers, developers gained and developers lost for each year from 1995 through 2016. I've attached a PDF of the spreadsheet. For example, in 1995 there were 3 developers (guess who). In 2016 there were 99 developers. By developer I mean at least one checkin to the repository. In 2010 we gained 23 developers but lost 48. Why? In 2016 we gained 28 but lost 50. I'll post the individual files on the VTK wiki. I'll also do the same measurements for ITK and Slicer. Bill -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: VTK.pdf Type: application/pdf Size: 23503 bytes Desc: not available URL: From lasso at queensu.ca Tue Aug 1 21:48:05 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 2 Aug 2017 01:48:05 +0000 Subject: [vtk-developers] VTK Developer Trends In-Reply-To: References: Message-ID: You can get some statistics from openhub (such as contributors per month, commits per month, ...): https://www.openhub.net/p/vtk https://www.openhub.net/p/itk https://www.openhub.net/p/slicer (due to some reason last analysis was done 8 months ago; also, most commits are received through github and committed to SVN, so number of integrators is reported as number of contributors) Andras -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen Sent: Tuesday, August 1, 2017 7:05 PM To: VTK Developers Subject: [vtk-developers] VTK Developer Trends Folks, There has been a lot of talk lately on the VTK and ITK lists about attracting more developers. Many subjective suggestions are being discussed. From my GE 6Sigma training, I recall that a more objective approach can be useful. The first step in the process is to measure, then analyze, followed by improve and control. I generated a spreadsheet that tracks the number of developers, developers gained and developers lost for each year from 1995 through 2016. I've attached a PDF of the spreadsheet. For example, in 1995 there were 3 developers (guess who). In 2016 there were 99 developers. By developer I mean at least one checkin to the repository. In 2010 we gained 23 developers but lost 48. Why? In 2016 we gained 28 but lost 50. I'll post the individual files on the VTK wiki. I'll also do the same measurements for ITK and Slicer. Bill -- Unpaid intern in BillsBasement at noware dot com From felix.morency at gmail.com Wed Aug 2 09:34:04 2017 From: felix.morency at gmail.com (=?UTF-8?Q?F=C3=A9lix_C=2E_Morency?=) Date: Wed, 2 Aug 2017 09:34:04 -0400 Subject: [vtk-developers] VTK Developer Trends In-Reply-To: References: Message-ID: I can only speak for me but I did some contribution a couple of years ago because we needed it at work. We still use VTK nowadays but we didn't encounter any issue lately that needed us to contribute. I am still lurking both mailing list daily and would contribute again if the need presents itself. -F On Tue, Aug 1, 2017 at 9:48 PM, Andras Lasso wrote: > You can get some statistics from openhub (such as contributors per month, commits per month, ...): > > https://www.openhub.net/p/vtk > > https://www.openhub.net/p/itk > > https://www.openhub.net/p/slicer (due to some reason last analysis was done 8 months ago; also, most commits are received through github and committed to SVN, so number of integrators is reported as number of contributors) > > Andras > > -----Original Message----- > From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Bill Lorensen > Sent: Tuesday, August 1, 2017 7:05 PM > To: VTK Developers > Subject: [vtk-developers] VTK Developer Trends > > Folks, > > There has been a lot of talk lately on the VTK and ITK lists about attracting more developers. Many subjective suggestions are being discussed. > > From my GE 6Sigma training, I recall that a more objective approach can be useful. > > The first step in the process is to measure, then analyze, followed by improve and control. > > I generated a spreadsheet that tracks the number of developers, developers gained and developers lost for each year from 1995 through 2016. I've attached a PDF of the spreadsheet. > > For example, in 1995 there were 3 developers (guess who). In 2016 there were 99 developers. By developer I mean at least one checkin to the repository. > > In 2010 we gained 23 developers but lost 48. Why? > In 2016 we gained 28 but lost 50. > > I'll post the individual files on the VTK wiki. I'll also do the same measurements for ITK and Slicer. > > 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 > From ken.martin at kitware.com Wed Aug 2 10:38:47 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 2 Aug 2017 10:38:47 -0400 Subject: [vtk-developers] Unused Template Warnings Message-ID: Do we care about these? Are they of value? I guess the question is should we fix or suppress? /Users/builder/external/VTK-clang-rel-x86_64/Common/Core/vtkSMPToolsInternal.h:24:13: warning: unused function template 'vtkSMPTools_Impl_For' [-Wunused-template] -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 sujin.philip at kitware.com Wed Aug 2 11:08:39 2017 From: sujin.philip at kitware.com (Sujin Philip) Date: Wed, 2 Aug 2017 11:08:39 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: Message-ID: Hi Ken, The vtkSMPTools.h header has parallel algorithms like For and Sort. I think this warning is occurring because some files that are including this are just using Sort. So, I think this warning should be suppressed or else we may have to refactor the code, which will not be a simple fix. Thanks Sujin On Wed, Aug 2, 2017 at 10:38 AM, Ken Martin wrote: > > Do we care about these? Are they of value? I guess the question is should > we fix or suppress? > > > /Users/builder/external/VTK-clang-rel-x86_64/Common/Core/vtkSMPToolsInternal.h:24:13: warning: unused function template 'vtkSMPTools_Impl_For' [-Wunused-template] > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Aug 2 14:51:42 2017 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 2 Aug 2017 14:51:42 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: Message-ID: Hmm it seems the llvm folks added this due to some ODR violation checking. That having it unused can cause it to be defined multiple times in a translation unit for some reason. It is all a bit beyond me. On Wed, Aug 2, 2017 at 11:08 AM, Sujin Philip wrote: > Hi Ken, > > The vtkSMPTools.h header has parallel algorithms like For and Sort. I > think this warning is occurring because some files that are including this > are just using Sort. So, I think this warning should be suppressed or else > we may have to refactor the code, which will not be a simple fix. > > Thanks > Sujin > > > On Wed, Aug 2, 2017 at 10:38 AM, Ken Martin > wrote: > >> >> Do we care about these? Are they of value? I guess the question is should >> we fix or suppress? >> >> >> /Users/builder/external/VTK-clang-rel-x86_64/Common/Core/vtkSMPToolsInternal.h:24:13: warning: unused function template 'vtkSMPTools_Impl_For' [-Wunused-template] >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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 Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 david.gobbi at gmail.com Wed Aug 2 15:10:02 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 2 Aug 2017 13:10:02 -0600 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: Message-ID: I wonder... perhaps clang only warns about these templates because they are declared as "static". It's generally expected that static functions will be used within the execution unit in which they are defined. If the "static" is removed, then the compiler should treat the templates as inline functions and it will let the linker deal with the ODR. Is there any reason not to remove "static" from the declarations of these templates? - David On Wed, Aug 2, 2017 at 12:51 PM, Ken Martin wrote: > Hmm it seems the llvm folks added this due to some ODR violation checking. > That having it unused can cause it to be defined multiple times in a > translation unit for some reason. It is all a bit beyond me. > > On Wed, Aug 2, 2017 at 11:08 AM, Sujin Philip > wrote: > >> Hi Ken, >> >> The vtkSMPTools.h header has parallel algorithms like For and Sort. I >> think this warning is occurring because some files that are including this >> are just using Sort. So, I think this warning should be suppressed or else >> we may have to refactor the code, which will not be a simple fix. >> >> Thanks >> Sujin >> >> >> On Wed, Aug 2, 2017 at 10:38 AM, Ken Martin >> wrote: >> >>> >>> Do we care about these? Are they of value? I guess the question is >>> should we fix or suppress? >>> >>> >>> /Users/builder/external/VTK-clang-rel-x86_64/Common/Core/vtkSMPToolsInternal.h:24:13: warning: unused function template 'vtkSMPTools_Impl_For' [-Wunused-template] >>> >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 28 Corporate Drive >>> Clifton Park NY 12065 >>> >>> 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 >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujin.philip at kitware.com Wed Aug 2 15:30:52 2017 From: sujin.philip at kitware.com (Sujin Philip) Date: Wed, 2 Aug 2017 15:30:52 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: Message-ID: I think it should be OK to remove `static`. Thanks Sujin On Wed, Aug 2, 2017 at 3:10 PM, David Gobbi wrote: > I wonder... perhaps clang only warns about these templates because they > are declared as "static". It's generally expected that static functions > will be used within the execution unit in which they are defined. If the > "static" is removed, then the compiler should treat the templates as inline > functions and it will let the linker deal with the ODR. > > Is there any reason not to remove "static" from the declarations of these > templates? > > - David > > > On Wed, Aug 2, 2017 at 12:51 PM, Ken Martin > wrote: > >> Hmm it seems the llvm folks added this due to some ODR violation >> checking. That having it unused can cause it to be defined multiple times >> in a translation unit for some reason. It is all a bit beyond me. >> >> On Wed, Aug 2, 2017 at 11:08 AM, Sujin Philip >> wrote: >> >>> Hi Ken, >>> >>> The vtkSMPTools.h header has parallel algorithms like For and Sort. I >>> think this warning is occurring because some files that are including this >>> are just using Sort. So, I think this warning should be suppressed or else >>> we may have to refactor the code, which will not be a simple fix. >>> >>> Thanks >>> Sujin >>> >>> >>> On Wed, Aug 2, 2017 at 10:38 AM, Ken Martin >>> wrote: >>> >>>> >>>> Do we care about these? Are they of value? I guess the question is >>>> should we fix or suppress? >>>> >>>> >>>> /Users/builder/external/VTK-clang-rel-x86_64/Common/Core/vtkSMPToolsInternal.h:24:13: warning: unused function template 'vtkSMPTools_Impl_For' [-Wunused-template] >>>> >>>> >>>> -- >>>> Ken Martin PhD >>>> Distinguished Engineer >>>> Kitware Inc. >>>> 28 Corporate Drive >>>> Clifton Park NY 12065 >>>> >>>> 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 >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Aug 3 13:28:21 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 3 Aug 2017 13:28:21 -0400 Subject: [vtk-developers] AAFrames/SubFrames/DOF Frames Message-ID: I am thinking about removing/deprecating these three features from VTK and figured I'd start by checking if any devs are using them. The goal being to reduce some code and prep for moving towards using a render pass by default. AAFrames is better handled with multisamples, SSAA or FXAA. For DOF there is now a render pass that uses modern approaches. -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 Thu Aug 3 15:16:45 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 3 Aug 2017 15:16:45 -0400 Subject: [vtk-developers] AAFrames/SubFrames/DOF Frames In-Reply-To: References: Message-ID: +1. This will be a good cleanup. On Thu, Aug 3, 2017 at 1:28 PM, Ken Martin wrote: > > I am thinking about removing/deprecating these three features from VTK and > figured I'd start by checking if any devs are using them. The goal being to > reduce some code and prep for moving towards using a render pass by default. > > AAFrames is better handled with multisamples, SSAA or FXAA. > > For DOF there is now a render pass that uses modern approaches. > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Aug 3 15:42:33 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 3 Aug 2017 15:42:33 -0400 Subject: [vtk-developers] AAFrames/SubFrames/DOF Frames In-Reply-To: References: Message-ID: +1 David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Aug 3, 2017 at 3:16 PM, Utkarsh Ayachit wrote: > +1. This will be a good cleanup. > > On Thu, Aug 3, 2017 at 1:28 PM, Ken Martin wrote: > >> >> I am thinking about removing/deprecating these three features from VTK >> and figured I'd start by checking if any devs are using them. The goal >> being to reduce some code and prep for moving towards using a render pass >> by default. >> >> AAFrames is better handled with multisamples, SSAA or FXAA. >> >> For DOF there is now a render pass that uses modern approaches. >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 28 Corporate Drive >> Clifton Park NY 12065 >> >> 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 >> >> >> > > _______________________________________________ > 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 Thu Aug 3 15:51:49 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 3 Aug 2017 15:51:49 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: Message-ID: <20170803195149.1272789750@mail.rogue-research.com> On Wed, 2 Aug 2017 15:30:52 -0400, Sujin Philip said: >I think it should be OK to remove `static`. If you create an MR I can try it on my bot. Sean From ken.martin at kitware.com Thu Aug 3 15:57:58 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 3 Aug 2017 15:57:58 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: <20170803195149.1272789750@mail.rogue-research.com> References: <20170803195149.1272789750@mail.rogue-research.com> Message-ID: Thanks Sean, we merged the change as it seems reasonable and we'll see tomorrow I guess. On Thu, Aug 3, 2017 at 3:51 PM, Sean McBride wrote: > On Wed, 2 Aug 2017 15:30:52 -0400, Sujin Philip said: > > >I think it should be OK to remove `static`. > > If you create an MR I can try it on my bot. > > Sean > > > _______________________________________________ > 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 Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 Aug 3 16:08:45 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 3 Aug 2017 16:08:45 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: <20170803195149.1272789750@mail.rogue-research.com> Message-ID: <20170803200845.149558297@mail.rogue-research.com> On Thu, 3 Aug 2017 15:57:58 -0400, Ken Martin said: >Thanks Sean, we merged the change as it seems reasonable and we'll see >tomorrow I guess. Oh. So on the topic of 'VTK developer workflow/survey'... :) How about we make it a habit to CC bot maintainers/contributors on MRs that fix issues on their bots? Would have saved me the last 30 minutes messing with this issue... :( :) Sean From ken.martin at kitware.com Thu Aug 3 16:20:14 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 3 Aug 2017 16:20:14 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: <20170803200845.149558297@mail.rogue-research.com> References: <20170803195149.1272789750@mail.rogue-research.com> <20170803200845.149558297@mail.rogue-research.com> Message-ID: I can try to remember, but I know that support at rogue-research.com probably means @seanm others may not know that mapping. More generally we sometimes do step on each others toes just because we don't realize someone else is working on something, or don't realize someone upgraded the OS on a buildbot etc. I suspect some folks may use the gitlab notifications to keep an eye on all new MRs just to know what is going on. I haven't tried that but I may give it a shake for VTK. On Thu, Aug 3, 2017 at 4:08 PM, Sean McBride wrote: > On Thu, 3 Aug 2017 15:57:58 -0400, Ken Martin said: > > >Thanks Sean, we merged the change as it seems reasonable and we'll see > >tomorrow I guess. > > Oh. > > So on the topic of 'VTK developer workflow/survey'... :) > > How about we make it a habit to CC bot maintainers/contributors on MRs > that fix issues on their bots? Would have saved me the last 30 minutes > messing with this issue... :( :) > > Sean > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 ben.boeckel at kitware.com Thu Aug 3 17:03:28 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 3 Aug 2017 17:03:28 -0400 Subject: [vtk-developers] Unused Template Warnings In-Reply-To: References: <20170803195149.1272789750@mail.rogue-research.com> <20170803200845.149558297@mail.rogue-research.com> Message-ID: <20170803210328.GA25073@megas.kitware.com> On Thu, Aug 03, 2017 at 16:20:14 -0400, Ken Martin wrote: > More generally we sometimes do step on each others toes just because we > don't realize someone else is working on something, or don't realize > someone upgraded the OS on a buildbot etc. I suspect some folks may use the > gitlab notifications to keep an eye on all new MRs just to know what is > going on. I haven't tried that but I may give it a shake for VTK. We can make a group on Gitlab that can be @ping'd. It'd be nice if Gitlab had orgs so that each group could have a "build maintainers" subgroup of each group that could be pinged individually. --Ben From aron.helser at kitware.com Fri Aug 4 09:45:13 2017 From: aron.helser at kitware.com (Aron Helser) Date: Fri, 4 Aug 2017 09:45:13 -0400 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? Message-ID: Hi David, all, I'm trying to re-write a C++ VTK method used in VTK web, to get rid of a base-64 string encoding of an image - so the C++ method I'm working on returns a buffer in a vtkUnsignedCharArray* to python. As a result, the python wrapping seems to return a 'str' type in both Python 2 and 3. The new result I want to return is a binary buffer (a raw JPG) - I tried returning the new result with the same type, and it gets cut off at the first null in the buffer. Is there a vtk return type should I be using instead? I've seen 'numpy_support' possibly used for this (and David D says he's used it in Cinema) but I'm not sure how it applies. Thanks! Aron -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Aug 4 10:30:16 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 4 Aug 2017 08:30:16 -0600 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 7:45 AM, Aron Helser wrote: > Hi David, all, > > I'm trying to re-write a C++ VTK method used in VTK web, to get rid of a > base-64 string encoding of an image - so the C++ method I'm working on > returns a buffer in a vtkUnsignedCharArray* to python. As a result, the > python wrapping seems to return a 'str' type in both Python 2 and 3. > The 'str' part doesn't make sense to me. What method are you calling to get an 'str' from a vtkUnsignedCharArray? > The new result I want to return is a binary buffer (a raw JPG) - I tried > returning the new result with the same type, and it gets cut off at the > first null in the buffer. Is there a vtk return type should I be using > instead? > You'll have to show me the python code that you're using. There is nothing in the wrappers themselves that would treat the contents of a vtkUnsignedCharArray is if they were a c-style string. Are you using a python "bytes" object as an intermediate? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron.helser at kitware.com Fri Aug 4 11:08:25 2017 From: aron.helser at kitware.com (Aron Helser) Date: Fri, 4 Aug 2017 11:08:25 -0400 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 10:30 AM, David Gobbi wrote: > On Fri, Aug 4, 2017 at 7:45 AM, Aron Helser > wrote: > >> Hi David, all, >> >> I'm trying to re-write a C++ VTK method used in VTK web, to get rid of a >> base-64 string encoding of an image - so the C++ method I'm working on >> returns a buffer in a vtkUnsignedCharArray* to python. As a result, the >> python wrapping seems to return a 'str' type in both Python 2 and 3. >> > > The 'str' part doesn't make sense to me. What method are you calling to > get an 'str' from a vtkUnsignedCharArray? > > >> The new result I want to return is a binary buffer (a raw JPG) - I tried >> returning the new result with the same type, and it gets cut off at the >> first null in the buffer. Is there a vtk return type should I be using >> instead? >> > > You'll have to show me the python code that you're using. There is > nothing in the wrappers themselves that would treat the contents of a > vtkUnsignedCharArray is if they were a c-style string. Are you using a > python "bytes" object as an intermediate? > Sure thing. And as I trace the code more carefully, I found at least part of the issue. I miss-spoke - the method in question is in ParaView, an override of a method in VTK: ParaView/Web/Core/vtkPVWebApplication.cxx: vtkUnsignedCharArray* vtkPVWebApplication::StillRender(vtkSMViewProxy* view, int quality) However, that method is wrapped in const char* vtkPVWebApplication::StillRenderToString(), which does this: return reinterpret_cast(array->GetPointer(0)); So that's where the 'char *' to python 'str' conversion happens. If I avoid that wrapper and return vtkUnsignedCharArray* directly, can I get a python 'bytes' object out of it in the Python code without copying? > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Fri Aug 4 11:53:45 2017 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 4 Aug 2017 15:53:45 +0000 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays Message-ID: Hi David, Users who mostly use VTK via Python wrapping are sometimes surprised how easily they can crash the application by accessing out-of-bounds elements in arrays. For example, this crashes an application: >>> a=vtk.vtkStringArray() >>> print(a.GetValue(0)) I first thought that it should be handled by documentation and training, but it would be nicer if the wrappers could handle this. Would it be feasible to add bounds check to VTK array accessors in Python wrappers, so that in case of an out of bounds access, a Python exception would be raised instead of crashing the application? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Aug 4 12:02:06 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 4 Aug 2017 10:02:06 -0600 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 9:08 AM, Aron Helser wrote: > > Sure thing. And as I trace the code more carefully, I found at least part > of the issue. > > I miss-spoke - the method in question is in ParaView, an override of a > method in VTK: > > ParaView/Web/Core/vtkPVWebApplication.cxx: > vtkUnsignedCharArray* vtkPVWebApplication::StillRender(vtkSMViewProxy* > view, int quality) > > However, that method is wrapped in const char* vtkPVWebApplication::StillRenderToString(), > which does this: > > > return reinterpret_cast(array->GetPointer(0)); > > So that's where the 'char *' to python 'str' conversion happens. > Yes, python will interpret a returned "char *" as a c-style string. One way to avoid this is to return an std::string, but std::string isn't useful when you're trying to do a zero-copy operation. If I avoid that wrapper and return vtkUnsignedCharArray* directly, can I > get a python 'bytes' object out of it in the Python code without copying? > Yes. In Python, the vtkUnsignedCharArray (and all other array types) support the Python buffer interface. That's a feature that Berk added to the wrappers a few years back. So if you were (hypothetically) using numpy, you could use numpy.frombuffer() to interpret the VTK array as a numpy array. This is a perfect zerocopy operation. The Python builtins, however, are more cautious about zerocopy than VTK or numpy. So if you were to simply do this, you'd get a copy: b = bytes(a) # where "a" is a VTK array object The Python "bytes" object is supposed to own its own memory, it wasn't designed to share. Even the numpy .tostring() and .tobytes() methods produce copies. However, I suspect that you don't have to convert the array to bytes anyway. Just pass the VTK array object to whatever method you were planning to pass the 'bytes' object to, and it will probably work fine. Many methods that take 'bytes' will actually take any object that provides a buffer interface, and that includes numpy arrays and VTK arrays. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Aug 4 12:22:51 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 4 Aug 2017 10:22:51 -0600 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: On Fri, Aug 4, 2017 at 10:02 AM, David Gobbi wrote: > On Fri, Aug 4, 2017 at 9:08 AM, Aron Helser > wrote: > >> >> Sure thing. And as I trace the code more carefully, I found at least part >> of the issue. >> >> I miss-spoke - the method in question is in ParaView, an override of a >> method in VTK: >> >> ParaView/Web/Core/vtkPVWebApplication.cxx: >> vtkUnsignedCharArray* vtkPVWebApplication::StillRender(vtkSMViewProxy* >> view, int quality) >> >> However, that method is wrapped in const char* >> vtkPVWebApplication::StillRenderToString(), which does this: >> >> >> return reinterpret_cast(array->GetPointer(0)); >> >> So that's where the 'char *' to python 'str' conversion happens. >> > > Yes, python will interpret a returned "char *" as a c-style string. One > way to avoid this is to return an std::string, but std::string isn't useful > when you're trying to do a zero-copy operation. > > > If I avoid that wrapper and return vtkUnsignedCharArray* directly, can I >> get a python 'bytes' object out of it in the Python code without copying? >> > > Yes. In Python, the vtkUnsignedCharArray (and all other array types) > support the Python buffer interface. That's a feature that Berk added to > the wrappers a few years back. > > So if you were (hypothetically) using numpy, you could use > numpy.frombuffer() to interpret the VTK array as a numpy array. This is a > perfect zerocopy operation. > > The Python builtins, however, are more cautious about zerocopy than VTK or > numpy. So if you were to simply do this, you'd get a copy: > > b = bytes(a) # where "a" is a VTK array object > > The Python "bytes" object is supposed to own its own memory, it wasn't > designed to share. Even the numpy .tostring() and .tobytes() methods > produce copies. > > However, I suspect that you don't have to convert the array to bytes > anyway. Just pass the VTK array object to whatever method you were > planning to pass the 'bytes' object to, and it will probably work fine. > Many methods that take 'bytes' will actually take any object that provides > a buffer interface, and that includes numpy arrays and VTK arrays. > I just remembered something else. The Python 'ctypes' module is another way of doing zerocopy. Here is some example code: c_type = ctypes.c_char*n # this means 'char [n]' c-style array c_array = c_type.from_buffer(a) # where 'a' is a VTK array So c_array is now shares memory with the VTK array. And you can use 'c_array.raw' to convert it into 'bytes', but like all the other methods we have seen that produce 'bytes', it produces a copy. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Aug 4 13:06:15 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 4 Aug 2017 11:06:15 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Hi Andras, Yes, this would be possible. It could be hard-coded into the wrappers, or even better, in the header file a generic hint could be added to the index parameter so that the index would be checked against the size of the array: float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK/Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed hints" section. I'm hoping to find time to implement more of these wrapper hints over the next few weeks. - David On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: > Hi David, > > > > Users who mostly use VTK via Python wrapping are sometimes surprised how > easily they can crash the application by accessing out-of-bounds elements > in arrays. For example, this crashes an application: > > > > >>> a=vtk.vtkStringArray() > > >>> print(a.GetValue(0)) > > > > I first thought that it should be handled by documentation and training, > but it would be nicer if the wrappers could handle this. > > > > Would it be feasible to add bounds check to VTK array accessors in Python > wrappers, so that in case of an out of bounds access, a Python exception > would be raised instead of crashing the application? > > Andras > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Fri Aug 4 13:11:52 2017 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 4 Aug 2017 17:11:52 +0000 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Thank you, it would be awesome to have this (and the other proposed hints, too). Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, August 4, 2017 1:06 PM To: Andras Lasso Cc: VTK Developers Subject: Re: Safer item access in Python wrapped VTK arrays Hi Andras, Yes, this would be possible. It could be hard-coded into the wrappers, or even better, in the header file a generic hint could be added to the index parameter so that the index would be checked against the size of the array: float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK/Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed hints" section. I'm hoping to find time to implement more of these wrapper hints over the next few weeks. - David On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso > wrote: Hi David, Users who mostly use VTK via Python wrapping are sometimes surprised how easily they can crash the application by accessing out-of-bounds elements in arrays. For example, this crashes an application: >>> a=vtk.vtkStringArray() >>> print(a.GetValue(0)) I first thought that it should be handled by documentation and training, but it would be nicer if the wrappers could handle this. Would it be feasible to add bounds check to VTK array accessors in Python wrappers, so that in case of an out of bounds access, a Python exception would be raised instead of crashing the application? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Aug 4 15:30:03 2017 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 4 Aug 2017 15:30:03 -0400 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: As much as I support the concept of range checking in the wrappers, this hint will make things look very ugly and non-standard at a time where we are trying to move towards more standard looking C++. Isn't there a way of doing this without mangling the signatures? On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi wrote: > Hi Andras, > > Yes, this would be possible. It could be hard-coded into the wrappers, or > even better, in the header file a generic hint could be added to the index > parameter so that the index would be checked against the size of the array: > > float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); > > I have a list of wrapper hints at http://www.vtk.org/Wiki/ > VTK/Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed > hints" section. > > I'm hoping to find time to implement more of these wrapper hints over the > next few weeks. > > - David > > > On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: > >> Hi David, >> >> >> >> Users who mostly use VTK via Python wrapping are sometimes surprised how >> easily they can crash the application by accessing out-of-bounds elements >> in arrays. For example, this crashes an application: >> >> >> >> >>> a=vtk.vtkStringArray() >> >> >>> print(a.GetValue(0)) >> >> >> >> I first thought that it should be handled by documentation and training, >> but it would be nicer if the wrappers could handle this. >> >> >> >> Would it be feasible to add bounds check to VTK array accessors in Python >> wrappers, so that in case of an out of bounds access, a Python exception >> would be raised instead of crashing the application? >> >> Andras >> > > > _______________________________________________ > 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 Aug 4 16:04:53 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 4 Aug 2017 14:04:53 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: For a while, we kicked around the idea of having the hints in the comments. This would be less intrusive than adding C++11 attributes the declarations (i.e. what I've been doing so far). The C++11 attributes are definitely the cleanest way for the wrappers to store the hints, since the hints become part of the parse tree, so I want to keep them as the primary hinting mechanism. Comment-based hints could be added as a secondary mechanism, i.e. after a declaration has been parsed we can check the docstring for extra hints, and then add the hints to the parse tree before the wrapper code is generated. I'll have to search through the archives to remember what kind of syntax we were considering for comment-based hints. - David On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci wrote: > As much as I support the concept of range checking in the wrappers, this > hint will make things look very ugly and non-standard at a time where we > are trying to move towards more standard looking C++. Isn't there a way of > doing this without mangling the signatures? > > On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi wrote: > >> Hi Andras, >> >> Yes, this would be possible. It could be hard-coded into the wrappers, >> or even better, in the header file a generic hint could be added to the >> index parameter so that the index would be checked against the size of the >> array: >> >> float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); >> >> I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK >> /Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed >> hints" section. >> >> I'm hoping to find time to implement more of these wrapper hints over the >> next few weeks. >> >> - David >> >> >> On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: >> >>> Hi David, >>> >>> >>> >>> Users who mostly use VTK via Python wrapping are sometimes surprised how >>> easily they can crash the application by accessing out-of-bounds elements >>> in arrays. For example, this crashes an application: >>> >>> >>> >>> >>> a=vtk.vtkStringArray() >>> >>> >>> print(a.GetValue(0)) >>> >>> >>> >>> I first thought that it should be handled by documentation and training, >>> but it would be nicer if the wrappers could handle this. >>> >>> >>> >>> Would it be feasible to add bounds check to VTK array accessors in >>> Python wrappers, so that in case of an out of bounds access, a Python >>> exception would be raised instead of crashing the application? >>> >>> Andras >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Fri Aug 4 21:39:54 2017 From: lasso at queensu.ca (Andras Lasso) Date: Sat, 5 Aug 2017 01:39:54 +0000 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Eventually, C++17 standard contracts may be used to specify these bounds checks. For now, we may use the same format but add them as comments or protected by macros; and when we switch to C++17 then these can be converted to actual contracts. Proposal for contracts: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4415.pdf Example contract: T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; For now, we could do this in VTK: T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, August 4, 2017 4:05 PM To: Berk Geveci Cc: Andras Lasso ; VTK Developers Subject: Re: [vtk-developers] Safer item access in Python wrapped VTK arrays For a while, we kicked around the idea of having the hints in the comments. This would be less intrusive than adding C++11 attributes the declarations (i.e. what I've been doing so far). The C++11 attributes are definitely the cleanest way for the wrappers to store the hints, since the hints become part of the parse tree, so I want to keep them as the primary hinting mechanism. Comment-based hints could be added as a secondary mechanism, i.e. after a declaration has been parsed we can check the docstring for extra hints, and then add the hints to the parse tree before the wrapper code is generated. I'll have to search through the archives to remember what kind of syntax we were considering for comment-based hints. - David On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci > wrote: As much as I support the concept of range checking in the wrappers, this hint will make things look very ugly and non-standard at a time where we are trying to move towards more standard looking C++. Isn't there a way of doing this without mangling the signatures? On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi > wrote: Hi Andras, Yes, this would be possible. It could be hard-coded into the wrappers, or even better, in the header file a generic hint could be added to the index parameter so that the index would be checked against the size of the array: float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK/Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed hints" section. I'm hoping to find time to implement more of these wrapper hints over the next few weeks. - David On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso > wrote: Hi David, Users who mostly use VTK via Python wrapping are sometimes surprised how easily they can crash the application by accessing out-of-bounds elements in arrays. For example, this crashes an application: >>> a=vtk.vtkStringArray() >>> print(a.GetValue(0)) I first thought that it should be handled by documentation and training, but it would be nicer if the wrappers could handle this. Would it be feasible to add bounds check to VTK array accessors in Python wrappers, so that in case of an out of bounds access, a Python exception would be raised instead of crashing the application? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Sat Aug 5 14:04:06 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Sat, 5 Aug 2017 23:34:06 +0530 Subject: [vtk-developers] Strange problem with vtkPLYReader Message-ID: Hi all, We've been running into a strange issue with the vtkPLYReader ever since VTK 5.6 all the way up to 8.0.0. I am attaching a simple VTK Python script. If you run it a few times you'll see inconsistent results for the bounds of the data like so: (0.0, 1.0, 0.0, 1.0, 0.0, 1.600000023841858) (0.0, 1.5845632502852868e+29, 0.0, 1.0, 0.0, 1.600000023841858) ... I've also attached a standard dataset for this. I could find the bug but I figured someone more familiar with the code may be quicker fixing it. Thanks! :) cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_ply_vtk.py Type: text/x-python-script Size: 273 bytes Desc: not available URL: -------------- next part -------------- ply format ascii 1.0 comment created by MATLAB ply_write element vertex 5 property float x property float y property float z element face 6 property list uchar char vertex_indices end_header 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 1.000000 1.000000 0.000000 0.000000 1.000000 0.000000 0.500000 0.500000 1.600000 3 2 1 4 3 2 4 3 3 1 2 5 3 1 5 4 3 4 5 3 3 2 3 5 From aron.helser at kitware.com Sun Aug 6 12:36:15 2017 From: aron.helser at kitware.com (Aron Helser) Date: Sun, 6 Aug 2017 12:36:15 -0400 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: Thank you for your suggestions and help. I got the ctypes method working in my code, then discovered that the websocket library I am using requires a 'bytes' object exactly - a bytes-like object won't do. So I am stuck doing a copy, I think. Thanks again! Aron On Fri, Aug 4, 2017 at 12:22 PM, David Gobbi wrote: > On Fri, Aug 4, 2017 at 10:02 AM, David Gobbi > wrote: > >> On Fri, Aug 4, 2017 at 9:08 AM, Aron Helser >> wrote: >> >>> >>> Sure thing. And as I trace the code more carefully, I found at least >>> part of the issue. >>> >>> I miss-spoke - the method in question is in ParaView, an override of a >>> method in VTK: >>> >>> ParaView/Web/Core/vtkPVWebApplication.cxx: >>> vtkUnsignedCharArray* vtkPVWebApplication::StillRender(vtkSMViewProxy* >>> view, int quality) >>> >>> However, that method is wrapped in const char* >>> vtkPVWebApplication::StillRenderToString(), which does this: >>> >>> >>> return reinterpret_cast(array->GetPointer(0)); >>> >>> So that's where the 'char *' to python 'str' conversion happens. >>> >> >> Yes, python will interpret a returned "char *" as a c-style string. One >> way to avoid this is to return an std::string, but std::string isn't useful >> when you're trying to do a zero-copy operation. >> >> >> If I avoid that wrapper and return vtkUnsignedCharArray* directly, can I >>> get a python 'bytes' object out of it in the Python code without copying? >>> >> >> Yes. In Python, the vtkUnsignedCharArray (and all other array types) >> support the Python buffer interface. That's a feature that Berk added to >> the wrappers a few years back. >> >> So if you were (hypothetically) using numpy, you could use >> numpy.frombuffer() to interpret the VTK array as a numpy array. This is a >> perfect zerocopy operation. >> >> The Python builtins, however, are more cautious about zerocopy than VTK >> or numpy. So if you were to simply do this, you'd get a copy: >> >> b = bytes(a) # where "a" is a VTK array object >> >> The Python "bytes" object is supposed to own its own memory, it wasn't >> designed to share. Even the numpy .tostring() and .tobytes() methods >> produce copies. >> >> However, I suspect that you don't have to convert the array to bytes >> anyway. Just pass the VTK array object to whatever method you were >> planning to pass the 'bytes' object to, and it will probably work fine. >> Many methods that take 'bytes' will actually take any object that provides >> a buffer interface, and that includes numpy arrays and VTK arrays. >> > > > I just remembered something else. The Python 'ctypes' module is another > way of doing zerocopy. Here is some example code: > > c_type = ctypes.c_char*n # this means 'char [n]' c-style array > c_array = c_type.from_buffer(a) # where 'a' is a VTK array > > So c_array is now shares memory with the VTK array. And you can use > 'c_array.raw' to convert it into 'bytes', but like all the other methods we > have seen that produce 'bytes', it produces a copy. > > - David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Aug 7 08:56:59 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 7 Aug 2017 06:56:59 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Hi Andras, I agree that these contracts are a better choice than inventing something of our own, I'm going to play around with this to see how easy it would be to add them to the wrappers. The macros can be made a little more compact: T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); Or we could use VTK_EXPECTS(i >= 0 && i < size()); - David On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso wrote: > Eventually, C++17 standard contracts may be used to specify these bounds > checks. For now, we may use the same format but add them as comments or > protected by macros; and when we switch to C++17 then these can be > converted to actual contracts. > > > > Proposal for contracts: http://www.open-std.org/JTC1/ > SC22/WG21/docs/papers/2015/n4415.pdf > > > > Example contract: > > T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; > > > > For now, we could do this in VTK: > > T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); > > > > Andras > > > > > > *From:* David Gobbi [mailto:david.gobbi at gmail.com] > *Sent:* Friday, August 4, 2017 4:05 PM > *To:* Berk Geveci > *Cc:* Andras Lasso ; VTK Developers < > vtk-developers at vtk.org> > *Subject:* Re: [vtk-developers] Safer item access in Python wrapped VTK > arrays > > > > For a while, we kicked around the idea of having the hints in the > comments. This would be less intrusive than adding C++11 attributes the > declarations (i.e. what I've been doing so far). > > > > The C++11 attributes are definitely the cleanest way for the wrappers to > store the hints, since the hints become part of the parse tree, so I want > to keep them as the primary hinting mechanism. Comment-based hints could > be added as a secondary mechanism, i.e. after a declaration has been parsed > we can check the docstring for extra hints, and then add the hints to the > parse tree before the wrapper code is generated. > > > > I'll have to search through the archives to remember what kind of syntax > we were considering for comment-based hints. > > > > - David > > > > > > On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci > wrote: > > As much as I support the concept of range checking in the wrappers, this > hint will make things look very ugly and non-standard at a time where we > are trying to move towards more standard looking C++. Isn't there a way of > doing this without mangling the signatures? > > > > On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi wrote: > > Hi Andras, > > > > Yes, this would be possible. It could be hard-coded into the wrappers, or > even better, in the header file a generic hint could be added to the index > parameter so that the index would be checked against the size of the array: > > > > float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); > > > > I have a list of wrapper hints at http://www.vtk.org/Wiki/ > VTK/Wrapping_hints > , > and I can add this "RANGECHECK" hint to the "Proposed hints" section. > > > > I'm hoping to find time to implement more of these wrapper hints over the > next few weeks. > > > > - David > > > > > > On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: > > Hi David, > > > > Users who mostly use VTK via Python wrapping are sometimes surprised how > easily they can crash the application by accessing out-of-bounds elements > in arrays. For example, this crashes an application: > > > > >>> a=vtk.vtkStringArray() > > >>> print(a.GetValue(0)) > > > > I first thought that it should be handled by documentation and training, > but it would be nicer if the wrappers could handle this. > > > > Would it be feasible to add bounds check to VTK array accessors in Python > wrappers, so that in case of an out of bounds access, a Python exception > would be raised instead of crashing the application? > > Andras > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron.helser at kitware.com Mon Aug 7 13:59:12 2017 From: aron.helser at kitware.com (Aron Helser) Date: Mon, 7 Aug 2017 13:59:12 -0400 Subject: [vtk-developers] VTK python wrapping - returning binary buffer to python? In-Reply-To: References: Message-ID: One more wrinkle, of course! This code you suggested works fine in Python3: b = bytes(a) # where "a" is a VTK array object Unfortunately, it doesn't work in Python 2.7 - it's returning the equivalent of str(a), which is info about the object: 'vtkUnsignedCharArray (00000000124BC8A0)\n Debug: Off\n Modified Time: 274789\n ....' So I'm going to switch to this: b = memoryview(a).tobytes() which will work in Python 2.7 and above, and should result in just one copy. Regards, Aron On Sun, Aug 6, 2017 at 12:36 PM, Aron Helser wrote: > Thank you for your suggestions and help. I got the ctypes method working > in my code, then discovered that the websocket library I am using requires > a 'bytes' object exactly - a bytes-like object won't do. So I am stuck > doing a copy, I think. > > Thanks again! > Aron > > On Fri, Aug 4, 2017 at 12:22 PM, David Gobbi > wrote: > >> On Fri, Aug 4, 2017 at 10:02 AM, David Gobbi >> wrote: >> >>> On Fri, Aug 4, 2017 at 9:08 AM, Aron Helser >>> wrote: >>> >>>> >>>> Sure thing. And as I trace the code more carefully, I found at least >>>> part of the issue. >>>> >>>> I miss-spoke - the method in question is in ParaView, an override of a >>>> method in VTK: >>>> >>>> ParaView/Web/Core/vtkPVWebApplication.cxx: >>>> vtkUnsignedCharArray* vtkPVWebApplication::StillRender(vtkSMViewProxy* >>>> view, int quality) >>>> >>>> However, that method is wrapped in const char* >>>> vtkPVWebApplication::StillRenderToString(), which does this: >>>> >>>> >>>> return reinterpret_cast(array->GetPointer(0)); >>>> >>>> So that's where the 'char *' to python 'str' conversion happens. >>>> >>> >>> Yes, python will interpret a returned "char *" as a c-style string. One >>> way to avoid this is to return an std::string, but std::string isn't useful >>> when you're trying to do a zero-copy operation. >>> >>> >>> If I avoid that wrapper and return vtkUnsignedCharArray* directly, can I >>>> get a python 'bytes' object out of it in the Python code without copying? >>>> >>> >>> Yes. In Python, the vtkUnsignedCharArray (and all other array types) >>> support the Python buffer interface. That's a feature that Berk added to >>> the wrappers a few years back. >>> >>> So if you were (hypothetically) using numpy, you could use >>> numpy.frombuffer() to interpret the VTK array as a numpy array. This is a >>> perfect zerocopy operation. >>> >>> The Python builtins, however, are more cautious about zerocopy than VTK >>> or numpy. So if you were to simply do this, you'd get a copy: >>> >>> b = bytes(a) # where "a" is a VTK array object >>> >>> The Python "bytes" object is supposed to own its own memory, it wasn't >>> designed to share. Even the numpy .tostring() and .tobytes() methods >>> produce copies. >>> >>> However, I suspect that you don't have to convert the array to bytes >>> anyway. Just pass the VTK array object to whatever method you were >>> planning to pass the 'bytes' object to, and it will probably work fine. >>> Many methods that take 'bytes' will actually take any object that provides >>> a buffer interface, and that includes numpy arrays and VTK arrays. >>> >> >> >> I just remembered something else. The Python 'ctypes' module is another >> way of doing zerocopy. Here is some example code: >> >> c_type = ctypes.c_char*n # this means 'char [n]' c-style array >> c_array = c_type.from_buffer(a) # where 'a' is a VTK array >> >> So c_array is now shares memory with the VTK array. And you can use >> 'c_array.raw' to convert it into 'bytes', but like all the other methods we >> have seen that produce 'bytes', it produces a copy. >> >> - David >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Aug 8 07:02:47 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 8 Aug 2017 13:02:47 +0200 Subject: [vtk-developers] 8.0.1 release? Message-ID: Hi all, To my great joy, Cory has fixed the Windows + old-ish Intel GPU rendering problems with QVTKOpenGLWidget that I reported in [1]. I verified the fix on our problematic machine today and closed the issue. It was the only one assigned to the 8.0.1 milestone AFAICS, so I was just going to ask if the 8.0.1 release is now coming soon? Until then we'll work with a VTK master snapshot. Elvis [1] https://gitlab.kitware.com/vtk/vtk/issues/17058 From sankhesh.jhaveri at kitware.com Wed Aug 9 09:55:14 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 09 Aug 2017 13:55:14 +0000 Subject: [vtk-developers] VTK java wrapping compile errors Message-ID: Folks, We ported an external project to a VTK module (vtkIOSegY) that leads to compile issues for java bindings. Anyone know how to fix the java wrapping errors here: https://open.cdash.org/viewBuildError.php?onlydeltap&buildid=5011596 The classes that it complains about are meant to be private implementations and not exported. Thank you! Sankhesh ? -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Aug 9 10:56:38 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Aug 2017 08:56:38 -0600 Subject: [vtk-developers] VTK java wrapping compile errors In-Reply-To: References: Message-ID: You can wrap-exclude them in the CMakeLists.txt: set_source_files_properties( vtkSegYIOUtils.cxx vtkSegYReader.cxx vtkSegYTraceReader.cxx WRAP_EXCLUDE ) And possibly this as well: set_source_files_properties( vtkSegYIOUtils.cxx vtkSegYReader.cxx vtkSegYTraceReader.cxx PROPERTIES WRAP_EXCLUDE_PYTHON 1 ) - David On Wed, Aug 9, 2017 at 7:55 AM, Sankhesh Jhaveri < sankhesh.jhaveri at kitware.com> wrote: > Folks, > > We ported an external project to a VTK module (vtkIOSegY) that leads to > compile issues for java bindings. > > Anyone know how to fix the java wrapping errors here: > > https://open.cdash.org/viewBuildError.php?onlydeltap&buildid=5011596 > > The classes that it complains about are meant to be private > implementations and not exported. > > Thank you! > Sankhesh > ? > -- > Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware > | (518) 881-4417 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Aug 9 11:53:44 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Aug 2017 09:53:44 -0600 Subject: [vtk-developers] VTK java wrapping compile errors In-Reply-To: References: Message-ID: In fact, it might be best to structure the CMakeLists.txt to separate the private classes into their own list: set(Module_SRCS vtkSegY2DReader.cxx vtkSegY3DReader.cxx ) set(Private_SRCS vtkSegYIOUtils.cxx vtkSegYReader.cxx vtkSegYTraceReader.cxx ) vtk_module_library(vtkIOSegY ${Module_SRCS} ${Private_SRCS}) set_source_files_properties(${Private_SRCS} WRAP_EXCLUDE) set_source_files_properties(${Private_SRCS} PROPERTIES WRAP_EXCLUDE_PYTHON 1) On Wed, Aug 9, 2017 at 8:56 AM, David Gobbi wrote: > > > On Wed, Aug 9, 2017 at 7:55 AM, Sankhesh Jhaveri < > sankhesh.jhaveri at kitware.com> wrote: > >> Folks, >> >> We ported an external project to a VTK module (vtkIOSegY) that leads to >> compile issues for java bindings. >> >> Anyone know how to fix the java wrapping errors here: >> >> https://open.cdash.org/viewBuildError.php?onlydeltap&buildid=5011596 >> >> The classes that it complains about are meant to be private >> implementations and not exported. >> >> Thank you! >> Sankhesh >> ? >> -- >> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >> | (518) 881-4417 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankhesh.jhaveri at kitware.com Wed Aug 9 12:23:01 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Wed, 09 Aug 2017 16:23:01 +0000 Subject: [vtk-developers] VTK java wrapping compile errors In-Reply-To: References: Message-ID: Cool, thanks David! I?ll create a new MR and ask you for review. ? On Wed, Aug 9, 2017 at 11:54 AM David Gobbi wrote: > In fact, it might be best to structure the CMakeLists.txt to separate the > private classes into their own list: > > set(Module_SRCS > > vtkSegY2DReader.cxx > > vtkSegY3DReader.cxx > > ) > > > > set(Private_SRCS > > vtkSegYIOUtils.cxx > > vtkSegYReader.cxx > > vtkSegYTraceReader.cxx > > ) > > > > vtk_module_library(vtkIOSegY ${Module_SRCS} ${Private_SRCS}) > > > > set_source_files_properties(${Private_SRCS} WRAP_EXCLUDE) > > set_source_files_properties(${Private_SRCS} PROPERTIES WRAP_EXCLUDE_PYTHON > 1) > > > > On Wed, Aug 9, 2017 at 8:56 AM, David Gobbi wrote: > >> >> >> On Wed, Aug 9, 2017 at 7:55 AM, Sankhesh Jhaveri < >> sankhesh.jhaveri at kitware.com> wrote: >> >>> Folks, >>> >>> We ported an external project to a VTK module (vtkIOSegY) that leads to >>> compile issues for java bindings. >>> >>> Anyone know how to fix the java wrapping errors here: >>> >>> https://open.cdash.org/viewBuildError.php?onlydeltap&buildid=5011596 >>> >>> The classes that it complains about are meant to be private >>> implementations and not exported. >>> >>> Thank you! >>> Sankhesh >>> ? >>> -- >>> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware >>> | (518) 881-4417 >>> >> > -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Aug 9 13:15:02 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 9 Aug 2017 13:15:02 -0400 Subject: [vtk-developers] 8.0.1 release? In-Reply-To: References: Message-ID: This and https://gitlab.kitware.com/vtk/vtk/merge_requests/2950 were the critical ones that I really wanted in 8.0.1. We'll try and get 8.0.1 by the end of the month. Note that we won't go through the usual RC cycle for the patch release. If things turn up we'll just make an 8.0.2. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 8, 2017 at 7:02 AM, Elvis Stansvik wrote: > Hi all, > > To my great joy, Cory has fixed the Windows + old-ish Intel GPU > rendering problems with QVTKOpenGLWidget that I reported in [1]. I > verified the fix on our problematic machine today and closed the > issue. > > It was the only one assigned to the 8.0.1 milestone AFAICS, so I was > just going to ask if the 8.0.1 release is now coming soon? Until then > we'll work with a VTK master snapshot. > > Elvis > > [1] https://gitlab.kitware.com/vtk/vtk/issues/17058 > _______________________________________________ > 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 elvis.stansvik at orexplore.com Wed Aug 9 13:31:17 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 9 Aug 2017 19:31:17 +0200 Subject: [vtk-developers] 8.0.1 release? In-Reply-To: References: Message-ID: Alright, thanks for the info David. That makes sense. Elvis 2017-08-09 19:15 GMT+02:00 David E DeMarle : > This and https://gitlab.kitware.com/vtk/vtk/merge_requests/2950 were the > critical ones that I really wanted in 8.0.1. > > We'll try and get 8.0.1 by the end of the month. Note that we won't go > through the usual RC cycle for the patch release. If things turn up we'll > just make an 8.0.2. > > > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Aug 8, 2017 at 7:02 AM, Elvis Stansvik > wrote: >> >> Hi all, >> >> To my great joy, Cory has fixed the Windows + old-ish Intel GPU >> rendering problems with QVTKOpenGLWidget that I reported in [1]. I >> verified the fix on our problematic machine today and closed the >> issue. >> >> It was the only one assigned to the 8.0.1 milestone AFAICS, so I was >> just going to ask if the 8.0.1 release is now coming soon? Until then >> we'll work with a VTK master snapshot. >> >> Elvis >> >> [1] https://gitlab.kitware.com/vtk/vtk/issues/17058 >> _______________________________________________ >> 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 Wed Aug 9 16:53:35 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Aug 2017 14:53:35 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Here's what I'm currently thinking about for wrapper hints, please let me know if the syntax is too obtrusive. The basic precondition contract, similar to proposed C++ contracts: float GetValue(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfValues()); And here's the format that I'm currently thinking about for wrapper size hints (to replace our "hints" file): double *GetPoint(vtkIdType i) VTK_SIZEHINT(return[3]); When used in combination things start to look ugly, but the method signature is still readable: void SetTuple(vtkIdType i, float *a) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(a[GetNumberOfComponents()]); float *GetTuple(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(return[GetNumberOfComponents()]); Any thoughts? I'd really like to express the size hint as some kind of contract, but C++ doesn't provide a way to check the number of values pointed to by a pointer. As an aside: for vtkDataArray, I don't actually intend to add VTK_SIZEHINT as shown above. Currently the size hints for vtkDataArray are hard-coded into the wrappers, and I'll probably keep them that way in order to keep the C++ headers clean. - David On Mon, Aug 7, 2017 at 6:56 AM, David Gobbi wrote: > Hi Andras, > > I agree that these contracts are a better choice than inventing something > of our own, I'm going to play around with this to see how easy it would be > to add them to the wrappers. > > The macros can be made a little more compact: > T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); > > Or we could use VTK_EXPECTS(i >= 0 && i < size()); > > - David > > > > On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso wrote: > >> Eventually, C++17 standard contracts may be used to specify these bounds >> checks. For now, we may use the same format but add them as comments or >> protected by macros; and when we switch to C++17 then these can be >> converted to actual contracts. >> >> >> >> Proposal for contracts: http://www.open-std.org/JTC1/S >> C22/WG21/docs/papers/2015/n4415.pdf >> >> >> >> Example contract: >> >> T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; >> >> >> >> For now, we could do this in VTK: >> >> T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); >> >> >> >> Andras >> >> >> >> >> >> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >> *Sent:* Friday, August 4, 2017 4:05 PM >> *To:* Berk Geveci >> *Cc:* Andras Lasso ; VTK Developers < >> vtk-developers at vtk.org> >> *Subject:* Re: [vtk-developers] Safer item access in Python wrapped VTK >> arrays >> >> >> >> For a while, we kicked around the idea of having the hints in the >> comments. This would be less intrusive than adding C++11 attributes the >> declarations (i.e. what I've been doing so far). >> >> >> >> The C++11 attributes are definitely the cleanest way for the wrappers to >> store the hints, since the hints become part of the parse tree, so I want >> to keep them as the primary hinting mechanism. Comment-based hints could >> be added as a secondary mechanism, i.e. after a declaration has been parsed >> we can check the docstring for extra hints, and then add the hints to the >> parse tree before the wrapper code is generated. >> >> >> >> I'll have to search through the archives to remember what kind of syntax >> we were considering for comment-based hints. >> >> >> >> - David >> >> >> >> >> >> On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci >> wrote: >> >> As much as I support the concept of range checking in the wrappers, this >> hint will make things look very ugly and non-standard at a time where we >> are trying to move towards more standard looking C++. Isn't there a way of >> doing this without mangling the signatures? >> >> >> >> On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi >> wrote: >> >> Hi Andras, >> >> >> >> Yes, this would be possible. It could be hard-coded into the wrappers, >> or even better, in the header file a generic hint could be added to the >> index parameter so that the index would be checked against the size of the >> array: >> >> >> >> float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); >> >> >> >> I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK >> /Wrapping_hints >> , >> and I can add this "RANGECHECK" hint to the "Proposed hints" section. >> >> >> >> I'm hoping to find time to implement more of these wrapper hints over the >> next few weeks. >> >> >> >> - David >> >> >> >> >> >> On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: >> >> Hi David, >> >> >> >> Users who mostly use VTK via Python wrapping are sometimes surprised how >> easily they can crash the application by accessing out-of-bounds elements >> in arrays. For example, this crashes an application: >> >> >> >> >>> a=vtk.vtkStringArray() >> >> >>> print(a.GetValue(0)) >> >> >> >> I first thought that it should be handled by documentation and training, >> but it would be nicer if the wrappers could handle this. >> >> >> >> Would it be feasible to add bounds check to VTK array accessors in Python >> wrappers, so that in case of an out of bounds access, a Python exception >> would be raised instead of crashing the application? >> >> Andras >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Aug 9 17:45:34 2017 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 9 Aug 2017 21:45:34 +0000 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: , Message-ID: For me, they look OK. VTK_SIZEHINT is not a beautiful syntax, but I understand why it is like this and don't have a better suggestion. How do you specify size hints for multiple arguments? Andras From: David Gobbi Sent: Wednesday, August 9, 2017 16:53 To: Andras Lasso; Berk Geveci Cc: VTK Developers Subject: Re: [vtk-developers] Safer item access in Python wrapped VTK arrays Here's what I'm currently thinking about for wrapper hints, please let me know if the syntax is too obtrusive. The basic precondition contract, similar to proposed C++ contracts: float GetValue(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfValues()); And here's the format that I'm currently thinking about for wrapper size hints (to replace our "hints" file): double *GetPoint(vtkIdType i) VTK_SIZEHINT(return[3]); When used in combination things start to look ugly, but the method signature is still readable: void SetTuple(vtkIdType i, float *a) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(a[GetNumberOfComponents()]); float *GetTuple(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(return[GetNumberOfComponents()]); Any thoughts? I'd really like to express the size hint as some kind of contract, but C++ doesn't provide a way to check the number of values pointed to by a pointer. As an aside: for vtkDataArray, I don't actually intend to add VTK_SIZEHINT as shown above. Currently the size hints for vtkDataArray are hard-coded into the wrappers, and I'll probably keep them that way in order to keep the C++ headers clean. - David On Mon, Aug 7, 2017 at 6:56 AM, David Gobbi > wrote: Hi Andras, I agree that these contracts are a better choice than inventing something of our own, I'm going to play around with this to see how easy it would be to add them to the wrappers. The macros can be made a little more compact: T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); Or we could use VTK_EXPECTS(i >= 0 && i < size()); - David On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso > wrote: Eventually, C++17 standard contracts may be used to specify these bounds checks. For now, we may use the same format but add them as comments or protected by macros; and when we switch to C++17 then these can be converted to actual contracts. Proposal for contracts: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4415.pdf Example contract: T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; For now, we could do this in VTK: T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); Andras From: David Gobbi [mailto:david.gobbi at gmail.com] Sent: Friday, August 4, 2017 4:05 PM To: Berk Geveci > Cc: Andras Lasso >; VTK Developers > Subject: Re: [vtk-developers] Safer item access in Python wrapped VTK arrays For a while, we kicked around the idea of having the hints in the comments. This would be less intrusive than adding C++11 attributes the declarations (i.e. what I've been doing so far). The C++11 attributes are definitely the cleanest way for the wrappers to store the hints, since the hints become part of the parse tree, so I want to keep them as the primary hinting mechanism. Comment-based hints could be added as a secondary mechanism, i.e. after a declaration has been parsed we can check the docstring for extra hints, and then add the hints to the parse tree before the wrapper code is generated. I'll have to search through the archives to remember what kind of syntax we were considering for comment-based hints. - David On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci > wrote: As much as I support the concept of range checking in the wrappers, this hint will make things look very ugly and non-standard at a time where we are trying to move towards more standard looking C++. Isn't there a way of doing this without mangling the signatures? On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi > wrote: Hi Andras, Yes, this would be possible. It could be hard-coded into the wrappers, or even better, in the header file a generic hint could be added to the index parameter so that the index would be checked against the size of the array: float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK/Wrapping_hints, and I can add this "RANGECHECK" hint to the "Proposed hints" section. I'm hoping to find time to implement more of these wrapper hints over the next few weeks. - David On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso > wrote: Hi David, Users who mostly use VTK via Python wrapping are sometimes surprised how easily they can crash the application by accessing out-of-bounds elements in arrays. For example, this crashes an application: >>> a=vtk.vtkStringArray() >>> print(a.GetValue(0)) I first thought that it should be handled by documentation and training, but it would be nicer if the wrappers could handle this. Would it be feasible to add bounds check to VTK array accessors in Python wrappers, so that in case of an out of bounds access, a Python exception would be raised instead of crashing the application? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Aug 9 18:24:44 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Aug 2017 16:24:44 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: On Wed, Aug 9, 2017 at 3:45 PM, Andras Lasso wrote: > For me, they look OK. > > > > VTK_SIZEHINT is not a beautiful syntax, but I understand why it is like > this and don't have a better suggestion.How do you specify size hints for > multiple arguments? > By having multiple VTK_SIZEHINT()s, one for each argument that requires a hint. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Thu Aug 10 02:44:41 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 10 Aug 2017 08:44:41 +0200 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: Den 9 aug. 2017 10:54 em skrev "David Gobbi" : Here's what I'm currently thinking about for wrapper hints, please let me know if the syntax is too obtrusive. The basic precondition contract, similar to proposed C++ contracts: float GetValue(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfValues()); This is really just a stylistic nitpick, and a matter of taste of course, so take it or leave it, but I like it when the var is in between the bounds, e.g. 0 <= i && i < GetNumberOfValues() As for the hint syntax, I also think what you last posted is readable enough. Elvis And here's the format that I'm currently thinking about for wrapper size hints (to replace our "hints" file): double *GetPoint(vtkIdType i) VTK_SIZEHINT(return[3]); When used in combination things start to look ugly, but the method signature is still readable: void SetTuple(vtkIdType i, float *a) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(a[GetNumberOfComponents()]); float *GetTuple(vtkIdType i) VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) VTK_SIZEHINT(return[GetNumberOfComponents()]); Any thoughts? I'd really like to express the size hint as some kind of contract, but C++ doesn't provide a way to check the number of values pointed to by a pointer. As an aside: for vtkDataArray, I don't actually intend to add VTK_SIZEHINT as shown above. Currently the size hints for vtkDataArray are hard-coded into the wrappers, and I'll probably keep them that way in order to keep the C++ headers clean. - David On Mon, Aug 7, 2017 at 6:56 AM, David Gobbi wrote: > Hi Andras, > > I agree that these contracts are a better choice than inventing something > of our own, I'm going to play around with this to see how easy it would be > to add them to the wrappers. > > The macros can be made a little more compact: > T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); > > Or we could use VTK_EXPECTS(i >= 0 && i < size()); > > - David > > > > On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso wrote: > >> Eventually, C++17 standard contracts may be used to specify these bounds >> checks. For now, we may use the same format but add them as comments or >> protected by macros; and when we switch to C++17 then these can be >> converted to actual contracts. >> >> >> >> Proposal for contracts: http://www.open-std.org/JTC1/S >> C22/WG21/docs/papers/2015/n4415.pdf >> >> >> >> Example contract: >> >> T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; >> >> >> >> For now, we could do this in VTK: >> >> T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); >> >> >> >> Andras >> >> >> >> >> >> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >> *Sent:* Friday, August 4, 2017 4:05 PM >> *To:* Berk Geveci >> *Cc:* Andras Lasso ; VTK Developers < >> vtk-developers at vtk.org> >> *Subject:* Re: [vtk-developers] Safer item access in Python wrapped VTK >> arrays >> >> >> >> For a while, we kicked around the idea of having the hints in the >> comments. This would be less intrusive than adding C++11 attributes the >> declarations (i.e. what I've been doing so far). >> >> >> >> The C++11 attributes are definitely the cleanest way for the wrappers to >> store the hints, since the hints become part of the parse tree, so I want >> to keep them as the primary hinting mechanism. Comment-based hints could >> be added as a secondary mechanism, i.e. after a declaration has been parsed >> we can check the docstring for extra hints, and then add the hints to the >> parse tree before the wrapper code is generated. >> >> >> >> I'll have to search through the archives to remember what kind of syntax >> we were considering for comment-based hints. >> >> >> >> - David >> >> >> >> >> >> On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci >> wrote: >> >> As much as I support the concept of range checking in the wrappers, this >> hint will make things look very ugly and non-standard at a time where we >> are trying to move towards more standard looking C++. Isn't there a way of >> doing this without mangling the signatures? >> >> >> >> On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi >> wrote: >> >> Hi Andras, >> >> >> >> Yes, this would be possible. It could be hard-coded into the wrappers, >> or even better, in the header file a generic hint could be added to the >> index parameter so that the index would be checked against the size of the >> array: >> >> >> >> float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); >> >> >> >> I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK >> /Wrapping_hints >> , >> and I can add this "RANGECHECK" hint to the "Proposed hints" section. >> >> >> >> I'm hoping to find time to implement more of these wrapper hints over the >> next few weeks. >> >> >> >> - David >> >> >> >> >> >> On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: >> >> Hi David, >> >> >> >> Users who mostly use VTK via Python wrapping are sometimes surprised how >> easily they can crash the application by accessing out-of-bounds elements >> in arrays. For example, this crashes an application: >> >> >> >> >>> a=vtk.vtkStringArray() >> >> >>> print(a.GetValue(0)) >> >> >> >> I first thought that it should be handled by documentation and training, >> but it would be nicer if the wrappers could handle this. >> >> >> >> Would it be feasible to add bounds check to VTK array accessors in Python >> wrappers, so that in case of an out of bounds access, a Python exception >> would be raised instead of crashing the application? >> >> Andras >> >> >> > > _______________________________________________ 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 dave.demarle at kitware.com Thu Aug 10 06:48:50 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 10 Aug 2017 06:48:50 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: References: Message-ID: Please submit a bug report via gitlab to help us keep track of this. On Aug 5, 2017 2:04 PM, "Prabhu Ramachandran" wrote: > Hi all, > > We've been running into a strange issue with the vtkPLYReader ever since > VTK 5.6 all the way up to 8.0.0. I am attaching a simple VTK Python > script. If you run it a few times you'll see inconsistent results for the > bounds of the data like so: > > (0.0, 1.0, 0.0, 1.0, 0.0, 1.600000023841858) > (0.0, 1.5845632502852868e+29, 0.0, 1.0, 0.0, 1.600000023841858) > > ... > > > I've also attached a standard dataset for this. I could find the bug but > I figured someone more familiar with the code may be quicker fixing it. > Thanks! :) > > > cheers, > > Prabhu > > _______________________________________________ > 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 Thu Aug 10 13:06:18 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Aug 2017 13:06:18 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: References: Message-ID: The PLYReader is fine. The file is not a proper PLY file. The face indices should be zero-based, but in this file they are one-based. So, the face 3 1 2 5 is referencing an point 5 which exceeds the points array which has tuples from 0 - 4 (5 points). On Thu, Aug 10, 2017 at 6:48 AM, David E DeMarle wrote: > Please submit a bug report via gitlab to help us keep track of this. > > On Aug 5, 2017 2:04 PM, "Prabhu Ramachandran" > wrote: >> >> Hi all, >> >> We've been running into a strange issue with the vtkPLYReader ever since >> VTK 5.6 all the way up to 8.0.0. I am attaching a simple VTK Python script. >> If you run it a few times you'll see inconsistent results for the bounds of >> the data like so: >> >> (0.0, 1.0, 0.0, 1.0, 0.0, 1.600000023841858) >> (0.0, 1.5845632502852868e+29, 0.0, 1.0, 0.0, 1.600000023841858) >> >> ... >> >> >> I've also attached a standard dataset for this. I could find the bug but >> I figured someone more familiar with the code may be quicker fixing it. >> Thanks! :) >> >> >> cheers, >> >> Prabhu >> >> >> _______________________________________________ >> 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 > > -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Thu Aug 10 13:29:58 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 10 Aug 2017 13:29:58 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: References: Message-ID: <20170810172958.894611623@mail.rogue-research.com> On Thu, 10 Aug 2017 13:06:18 -0400, Bill Lorensen said: >The PLYReader is fine. The file is not a proper PLY file. The face >indices should be zero-based, but in this file they are one-based. So, >the face >3 1 2 5 >is referencing an point 5 which exceeds the points array which has >tuples from 0 - 4 (5 points). In which case one may reasonably argue that the PLYReader is indeed broken, for failing to reject invalid files. Under ASan/valgrind, would the PLYReader crash with this file? Sean From bill.lorensen at gmail.com Thu Aug 10 13:32:45 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Aug 2017 13:32:45 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: <20170810172958.894611623@mail.rogue-research.com> References: <20170810172958.894611623@mail.rogue-research.com> Message-ID: I found the error with valgrind... On Thu, Aug 10, 2017 at 1:29 PM, Sean McBride wrote: > On Thu, 10 Aug 2017 13:06:18 -0400, Bill Lorensen said: > >>The PLYReader is fine. The file is not a proper PLY file. The face >>indices should be zero-based, but in this file they are one-based. So, >>the face >>3 1 2 5 >>is referencing an point 5 which exceeds the points array which has >>tuples from 0 - 4 (5 points). > > In which case one may reasonably argue that the PLYReader is indeed broken, for failing to reject invalid files. Under ASan/valgrind, would the PLYReader crash with this file? > > Sean > > -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Thu Aug 10 13:38:28 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 10 Aug 2017 13:38:28 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: <20170810172958.894611623@mail.rogue-research.com> References: <20170810172958.894611623@mail.rogue-research.com> Message-ID: Sean- In which case one may reasonably argue that the PLYReader is indeed broken, > for failing to reject invalid files. You are opening a can of worms here. I would humbly suggest that in most all file formats in VTK if the data is invalid then bad things will happen. If you want to make a sanity check as part of the read process then do it as an optional step because fully vetting data can take forever. Best, W On Thu, Aug 10, 2017 at 1:29 PM, Sean McBride wrote: > On Thu, 10 Aug 2017 13:06:18 -0400, Bill Lorensen said: > > >The PLYReader is fine. The file is not a proper PLY file. The face > >indices should be zero-based, but in this file they are one-based. So, > >the face > >3 1 2 5 > >is referencing an point 5 which exceeds the points array which has > >tuples from 0 - 4 (5 points). > > In which case one may reasonably argue that the PLYReader is indeed > broken, for failing to reject invalid files. Under ASan/valgrind, would > the PLYReader crash with this file? > > Sean > > > _______________________________________________ > 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 > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 10 13:59:42 2017 From: sean at rogue-research.com (Sean McBride) Date: Thu, 10 Aug 2017 13:59:42 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: References: <20170810172958.894611623@mail.rogue-research.com> Message-ID: <20170810175942.547023220@mail.rogue-research.com> On Thu, 10 Aug 2017 13:38:28 -0400, Will Schroeder said: >>In which case one may reasonably argue that the PLYReader is indeed broken, >>for failing to reject invalid files. > >You are opening a can of worms here. I would humbly suggest that in most >all file formats in VTK if the data is invalid then bad things will happen. Yup, which is a huge weakness of VTK, IMNSHO. >If you want to make a sanity check as part of the read process then do it >as an optional step because fully vetting data can take forever. Vetting the data does take time, yes. Sometimes the code can be factored such that the validation happens at one level, and some lower level function can assume it's valid. But the alternative is crashing upon invalid data. That's bad, especially when dealing with data from untrusted sources like files or the network. This is how we're in a world where opening maliciously crafted jpeg/pdf/font/etc files can be used to run arbitrary code and do all kinds of nastiness. If I had infinite time, fuzzing the VTK readers would be a fun project... Sean From david.thompson at kitware.com Thu Aug 10 14:12:25 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 10 Aug 2017 14:12:25 -0400 Subject: [vtk-developers] vtkOpenGLVertexBufferObjectGroup Message-ID: Hi all (but esp. Ken and Alexis), I'm working on a project to use VTK's mappers to render VTK-m data (already resident on the GPU but not necessarily exposed to OpenGL). Recently the vtkOpenGLPolyDataMapper was refactored to keep VBOs in the new vtkOpenGLVertexBufferObjectGroup class. This makes using the shaders in the mapper difficult because the buffer-group uploads arrays to the VBOs (which we want to avoid because the arrays are already on the GPU) and creates VBOs (meaning there is no way to create subclass of vtkOpenGLVertexBufferObject that overrides Upload() or something similar). Do you have any ideas about how we might change the buffer-object-group to allow zero-transfer VTK-m arrays to be handled without uploading them? Perhaps we could add a method to vtkOpenGLVertexBufferObject that visits all the arrays for each VBO it has created? class vtkOpenGLVertexBufferObject { ... void VisitAllVBOs( vtkOpenGLVertexBufferObjectCache* vtkNotUsed(cache), std::function visitor) { for (arrayIter bi = this->UsedDataArrays.begin(); bi != this->UsedDataArrays.end(); ++bi) { for (auto ai : bi->second) { visitor(bi->first, this->UsedVBOs[bi->first], ai); } } } ... }; This would get us 90% of the way to VTKm-based mappers (subclasses of vtkOpenGLPolyDataMapper), since we could write a visitor and skip the BuildAllVBOs() call. Thanks, David From elvis.stansvik at orexplore.com Thu Aug 10 14:12:32 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 10 Aug 2017 20:12:32 +0200 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: <20170810175942.547023220@mail.rogue-research.com> References: <20170810172958.894611623@mail.rogue-research.com> <20170810175942.547023220@mail.rogue-research.com> Message-ID: 2017-08-10 19:59 GMT+02:00 Sean McBride : > On Thu, 10 Aug 2017 13:38:28 -0400, Will Schroeder said: > >>>In which case one may reasonably argue that the PLYReader is indeed broken, >>>for failing to reject invalid files. >> >>You are opening a can of worms here. I would humbly suggest that in most >>all file formats in VTK if the data is invalid then bad things will happen. > > Yup, which is a huge weakness of VTK, IMNSHO. > >>If you want to make a sanity check as part of the read process then do it >>as an optional step because fully vetting data can take forever. > > Vetting the data does take time, yes. Sometimes the code can be factored such that the validation happens at one level, and some lower level function can assume it's valid. > > But the alternative is crashing upon invalid data. That's bad, especially when dealing with data from untrusted sources like files or the network. This is how we're in a world where opening maliciously crafted jpeg/pdf/font/etc files can be used to run arbitrary code and do all kinds of nastiness. +1 I would think that for most applications, crashing hard upon opening a faulty file is not an option, and not having the library fail gracefully just forces applications to vet the data themselves, which in some (many?) cases may be even more costly than had the library done it during loading. I think the Robustness principle very much applies here [1]. But yes, time... Elvis [1] https://en.wikipedia.org/wiki/Robustness_principle > > If I had infinite time, fuzzing the VTK readers would be a fun project... > > Sean > > > _______________________________________________ > 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 will.schroeder at kitware.com Thu Aug 10 14:22:12 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 10 Aug 2017 14:22:12 -0400 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: <20170810175942.547023220@mail.rogue-research.com> References: <20170810172958.894611623@mail.rogue-research.com> <20170810175942.547023220@mail.rogue-research.com> Message-ID: > > Yup, which is a huge weakness of VTK, IMNSHO. Actually this is true of almost every scientific computing program that I have ever used, not just VTK. But the alternative is crashing upon invalid data. Another alternative is to assume that users are intelligent and know what they are doing and can figure out problems (very naive I know) :-) Vetting data is simple in concept but way worse than we think because if you carry it to extreme you've got to do things like check whether polygons are flat/non-self intersecting, cells are not turned inside out, data values are valid and indeed within the range specified, data time series are mutually consistent, etc. Like everything there are tradeoffs between getting stuff done and perfection, whatever the heck that is anyway :-) There are reasonable things to do but all in balance. I am going to continue to advocate that we need to keep thinking about new algorithms and designs (high-level stuff) and avoid getting stuck in the morass of technical perfection. What makes systems successful in the end are impactful capabilities--solving important problems--not the perfection of implementation. So if you've got some cycles to fuzz, I would go in the directions of added capabilities :-) Best, W On Thu, Aug 10, 2017 at 1:59 PM, Sean McBride wrote: > On Thu, 10 Aug 2017 13:38:28 -0400, Will Schroeder said: > > >>In which case one may reasonably argue that the PLYReader is indeed > broken, > >>for failing to reject invalid files. > > > >You are opening a can of worms here. I would humbly suggest that in most > >all file formats in VTK if the data is invalid then bad things will > happen. > > Yup, which is a huge weakness of VTK, IMNSHO. > > >If you want to make a sanity check as part of the read process then do it > >as an optional step because fully vetting data can take forever. > > Vetting the data does take time, yes. Sometimes the code can be factored > such that the validation happens at one level, and some lower level > function can assume it's valid. > > But the alternative is crashing upon invalid data. That's bad, especially > when dealing with data from untrusted sources like files or the network. > This is how we're in a world where opening maliciously crafted > jpeg/pdf/font/etc files can be used to run arbitrary code and do all kinds > of nastiness. > > If I had infinite time, fuzzing the VTK readers would be a fun project... > > Sean > > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Fri Aug 11 03:01:48 2017 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Fri, 11 Aug 2017 12:31:48 +0530 Subject: [vtk-developers] Strange problem with vtkPLYReader In-Reply-To: References: Message-ID: <42084705-49c9-c3a3-55e7-3b9bbbfc170d@aero.iitb.ac.in> Hi Bill, This is very embarrassing! Thank you for finding the source of the problem. I had assumed that the file was a standard one but apparently a buggy writer had generated it in the past. While it would be nice to have readers detect these I understand that this is going to be hard. Thanks again and sorry for the noise! cheers, Prabhu On 8/10/17 10:36 PM, Bill Lorensen wrote: > The PLYReader is fine. The file is not a proper PLY file. The face > indices should be zero-based, but in this file they are one-based. So, > the face > 3 1 2 5 > is referencing an point 5 which exceeds the points array which has > tuples from 0 - 4 (5 points). > > On Thu, Aug 10, 2017 at 6:48 AM, David E DeMarle > wrote: >> Please submit a bug report via gitlab to help us keep track of this. >> >> On Aug 5, 2017 2:04 PM, "Prabhu Ramachandran" >> wrote: >>> Hi all, >>> >>> We've been running into a strange issue with the vtkPLYReader ever since >>> VTK 5.6 all the way up to 8.0.0. I am attaching a simple VTK Python script. >>> If you run it a few times you'll see inconsistent results for the bounds of >>> the data like so: >>> >>> (0.0, 1.0, 0.0, 1.0, 0.0, 1.600000023841858) >>> (0.0, 1.5845632502852868e+29, 0.0, 1.0, 0.0, 1.600000023841858) >>> >>> ... >>> >>> >>> I've also attached a standard dataset for this. I could find the bug but >>> I figured someone more familiar with the code may be quicker fixing it. >>> Thanks! :) >>> >>> >>> cheers, >>> >>> Prabhu >>> >>> >>> _______________________________________________ >>> 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 sean at rogue-research.com Wed Aug 16 09:39:12 2017 From: sean at rogue-research.com (Sean McBride) Date: Wed, 16 Aug 2017 09:39:12 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... Message-ID: <20170816133912.1633053705@mail.rogue-research.com> Hi all, 1) the new cppcheck warnings on Rogue7 are because I updated it from cppcheck 1.79 to 1.80. I'll triage those issues, fix what I can, suppress false positives, then write back here if there are some I'm not sure about. 2) my Xcode-generator dashboard broke at some point. I didn't notice when. cdash is not being helpful with its output: https://open.cdash.org/viewBuildError.php?type=1&buildid=5019782 I ran it manually with -VV and one warning I see is: ------ CMake Deprecation Warning at ThirdParty/libproj4/vtklibproj4/cmake/policies.cmake:2 (cmake_policy): The OLD behavior for policy CMP0022 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. Call Stack (most recent call first): ThirdParty/libproj4/vtklibproj4/CMakeLists.txt:43 (include) ------ Could that be the cause? 3) there are a bunch of -Wunused-template and -Wshadow-field warnings. The former I lack the C++ skills to fix, the latter need someone that knows the class in question. (It's always hard to know if shadowing meant to use the superclass variable or just needs a rename...) Can someone look at these? Thanks, Sean From andy.bauer at kitware.com Wed Aug 16 09:51:27 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 16 Aug 2017 09:51:27 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: <20170816133912.1633053705@mail.rogue-research.com> References: <20170816133912.1633053705@mail.rogue-research.com> Message-ID: Hi Sean, For #3 (-Wunused-template and -Wshadow-field warnings), could you point me to the dashboard warnings? The one that looks most appropriate to me is at https://open.cdash.org/viewBuildError.php?type=1&buildid=5019417 but I don't see any of those warnings. That does have some warnings though that seem simple enough to fix as well though with the help of the community. Thanks, Andy On Wed, Aug 16, 2017 at 9:39 AM, Sean McBride wrote: > Hi all, > > 1) the new cppcheck warnings on Rogue7 are because I updated it from > cppcheck 1.79 to 1.80. I'll triage those issues, fix what I can, suppress > false positives, then write back here if there are some I'm not sure about. > > > 2) my Xcode-generator dashboard broke at some point. I didn't notice > when. cdash is not being helpful with its output: > > https://open.cdash.org/viewBuildError.php?type=1&buildid=5019782 > > I ran it manually with -VV and one warning I see is: > > ------ > CMake Deprecation Warning at ThirdParty/libproj4/ > vtklibproj4/cmake/policies.cmake:2 (cmake_policy): > The OLD behavior for policy CMP0022 will be removed from a future version > of CMake. > > The cmake-policies(7) manual explains that the OLD behaviors of all > policies are deprecated and that a policy should be set to OLD only under > specific short-term circumstances. Projects should be ported to the NEW > behavior and not rely on setting a policy to OLD. > Call Stack (most recent call first): > ThirdParty/libproj4/vtklibproj4/CMakeLists.txt:43 (include) > ------ > > Could that be the cause? > > > 3) there are a bunch of -Wunused-template and -Wshadow-field warnings. > The former I lack the C++ skills to fix, the latter need someone that knows > the class in question. (It's always hard to know if shadowing meant to use > the superclass variable or just needs a rename...) Can someone look at > these? > > Thanks, > > Sean > > > _______________________________________________ > 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 Wed Aug 16 10:01:21 2017 From: sean at rogue-research.com (Sean McBride) Date: Wed, 16 Aug 2017 10:01:21 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> Message-ID: <20170816140121.825524940@mail.rogue-research.com> No, those are #1 below. For #3, see: It looks like a tonne of warnings, but many are repeated. Sean On Wed, 16 Aug 2017 09:51:27 -0400, Andy Bauer said: >Hi Sean, > >For #3 (-Wunused-template and -Wshadow-field warnings), could you point me >to the dashboard warnings? The one that looks most appropriate to me is at >https://open.cdash.org/viewBuildError.php?type=1&buildid=5019417 but I >don't see any of those warnings. That does have some warnings though that >seem simple enough to fix as well though with the help of the community. > >Thanks, >Andy > >On Wed, Aug 16, 2017 at 9:39 AM, Sean McBride >wrote: > >> Hi all, >> >> 1) the new cppcheck warnings on Rogue7 are because I updated it from >> cppcheck 1.79 to 1.80. I'll triage those issues, fix what I can, suppress >> false positives, then write back here if there are some I'm not sure about. >> >> >> 2) my Xcode-generator dashboard broke at some point. I didn't notice >> when. cdash is not being helpful with its output: >> >> https://open.cdash.org/viewBuildError.php?type=1&buildid=5019782 >> >> I ran it manually with -VV and one warning I see is: >> >> ------ >> CMake Deprecation Warning at ThirdParty/libproj4/ >> vtklibproj4/cmake/policies.cmake:2 (cmake_policy): >> The OLD behavior for policy CMP0022 will be removed from a future version >> of CMake. >> >> The cmake-policies(7) manual explains that the OLD behaviors of all >> policies are deprecated and that a policy should be set to OLD only under >> specific short-term circumstances. Projects should be ported to the NEW >> behavior and not rely on setting a policy to OLD. >> Call Stack (most recent call first): >> ThirdParty/libproj4/vtklibproj4/CMakeLists.txt:43 (include) >> ------ >> >> Could that be the cause? >> >> >> 3) there are a bunch of -Wunused-template and -Wshadow-field warnings. >> The former I lack the C++ skills to fix, the latter need someone that knows >> the class in question. (It's always hard to know if shadowing meant to use >> the superclass variable or just needs a rename...) Can someone look at >> these? >> >> Thanks, >> >> Sean >> >> >> _______________________________________________ >> 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 andy.bauer at kitware.com Wed Aug 16 10:27:02 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 16 Aug 2017 10:27:02 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: <20170816140121.825524940@mail.rogue-research.com> References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> Message-ID: Hi Sean, Thanks for providing the link for #3. I'll handle the XML readers and writers, vtkStreaklineFilter and particle path warnings. Allison, do you think you can work on the data array warnings? I think if both Allison and I take care of those it should whittle down the list to a more manageable size to start getting others to help out with. Best, Andy On Wed, Aug 16, 2017 at 10:01 AM, Sean McBride wrote: > No, those are #1 below. For #3, see: > > > > It looks like a tonne of warnings, but many are repeated. > > Sean > > > > On Wed, 16 Aug 2017 09:51:27 -0400, Andy Bauer said: > > >Hi Sean, > > > >For #3 (-Wunused-template and -Wshadow-field warnings), could you point me > >to the dashboard warnings? The one that looks most appropriate to me is at > >https://open.cdash.org/viewBuildError.php?type=1&buildid=5019417 but I > >don't see any of those warnings. That does have some warnings though that > >seem simple enough to fix as well though with the help of the community. > > > >Thanks, > >Andy > > > >On Wed, Aug 16, 2017 at 9:39 AM, Sean McBride > >wrote: > > > >> Hi all, > >> > >> 1) the new cppcheck warnings on Rogue7 are because I updated it from > >> cppcheck 1.79 to 1.80. I'll triage those issues, fix what I can, > suppress > >> false positives, then write back here if there are some I'm not sure > about. > >> > >> > >> 2) my Xcode-generator dashboard broke at some point. I didn't notice > >> when. cdash is not being helpful with its output: > >> > >> https://open.cdash.org/viewBuildError.php?type=1&buildid=5019782 > >> > >> I ran it manually with -VV and one warning I see is: > >> > >> ------ > >> CMake Deprecation Warning at ThirdParty/libproj4/ > >> vtklibproj4/cmake/policies.cmake:2 (cmake_policy): > >> The OLD behavior for policy CMP0022 will be removed from a future > version > >> of CMake. > >> > >> The cmake-policies(7) manual explains that the OLD behaviors of all > >> policies are deprecated and that a policy should be set to OLD only > under > >> specific short-term circumstances. Projects should be ported to the > NEW > >> behavior and not rely on setting a policy to OLD. > >> Call Stack (most recent call first): > >> ThirdParty/libproj4/vtklibproj4/CMakeLists.txt:43 (include) > >> ------ > >> > >> Could that be the cause? > >> > >> > >> 3) there are a bunch of -Wunused-template and -Wshadow-field warnings. > >> The former I lack the C++ skills to fix, the latter need someone that > knows > >> the class in question. (It's always hard to know if shadowing meant to > use > >> the superclass variable or just needs a rename...) Can someone look at > >> these? > >> > >> Thanks, > >> > >> Sean > >> > >> > >> _______________________________________________ > >> 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 Wed Aug 16 11:28:06 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Wed, 16 Aug 2017 11:28:06 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> Message-ID: FYI: I have a VTK MR at https://gitlab.kitware.com/vtk/vtk/merge_requests/3156 that should take care of the warnings from stuff in IO/XML, IO/ParallelXML, Filters/Parallel and Filters/FlowPaths. I'd guesstimate that this will reduce the compiler warnings by nearly half. Thanks for pushing on this Sean! On Wed, Aug 16, 2017 at 10:27 AM, Andy Bauer wrote: > Hi Sean, > > Thanks for providing the link for #3. I'll handle the XML readers and > writers, vtkStreaklineFilter and particle path warnings. > > Allison, do you think you can work on the data array warnings? > > I think if both Allison and I take care of those it should whittle down > the list to a more manageable size to start getting others to help out with. > > Best, > Andy > > On Wed, Aug 16, 2017 at 10:01 AM, Sean McBride > wrote: > >> No, those are #1 below. For #3, see: >> >> >> >> It looks like a tonne of warnings, but many are repeated. >> >> Sean >> >> >> >> On Wed, 16 Aug 2017 09:51:27 -0400, Andy Bauer said: >> >> >Hi Sean, >> > >> >For #3 (-Wunused-template and -Wshadow-field warnings), could you point >> me >> >to the dashboard warnings? The one that looks most appropriate to me is >> at >> >https://open.cdash.org/viewBuildError.php?type=1&buildid=5019417 but I >> >don't see any of those warnings. That does have some warnings though that >> >seem simple enough to fix as well though with the help of the community. >> > >> >Thanks, >> >Andy >> > >> >On Wed, Aug 16, 2017 at 9:39 AM, Sean McBride >> >wrote: >> > >> >> Hi all, >> >> >> >> 1) the new cppcheck warnings on Rogue7 are because I updated it from >> >> cppcheck 1.79 to 1.80. I'll triage those issues, fix what I can, >> suppress >> >> false positives, then write back here if there are some I'm not sure >> about. >> >> >> >> >> >> 2) my Xcode-generator dashboard broke at some point. I didn't notice >> >> when. cdash is not being helpful with its output: >> >> >> >> https://open.cdash.org/viewBuildError.php?type=1&buildid=5019782 >> >> >> >> I ran it manually with -VV and one warning I see is: >> >> >> >> ------ >> >> CMake Deprecation Warning at ThirdParty/libproj4/ >> >> vtklibproj4/cmake/policies.cmake:2 (cmake_policy): >> >> The OLD behavior for policy CMP0022 will be removed from a future >> version >> >> of CMake. >> >> >> >> The cmake-policies(7) manual explains that the OLD behaviors of all >> >> policies are deprecated and that a policy should be set to OLD only >> under >> >> specific short-term circumstances. Projects should be ported to the >> NEW >> >> behavior and not rely on setting a policy to OLD. >> >> Call Stack (most recent call first): >> >> ThirdParty/libproj4/vtklibproj4/CMakeLists.txt:43 (include) >> >> ------ >> >> >> >> Could that be the cause? >> >> >> >> >> >> 3) there are a bunch of -Wunused-template and -Wshadow-field warnings. >> >> The former I lack the C++ skills to fix, the latter need someone that >> knows >> >> the class in question. (It's always hard to know if shadowing meant >> to use >> >> the superclass variable or just needs a rename...) Can someone look at >> >> these? >> >> >> >> Thanks, >> >> >> >> Sean >> >> >> >> >> >> _______________________________________________ >> >> 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 allison.vacanti at kitware.com Wed Aug 16 13:54:26 2017 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Wed, 16 Aug 2017 13:54:26 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> Message-ID: On Wed, Aug 16, 2017 at 10:27 AM, Andy Bauer wrote: > Allison, do you think you can work on the data array warnings? > > I think if both Allison and I take care of those it should whittle down the > list to a more manageable size to start getting others to help out with. I think we should just disable the unused-template warnings. Most of these cases depend on the ArrayDispatch configuration and can't be removed without breaking features, even though some builds don't use them. For instance, many of these are specialized overloads for workers that optimize for vtkSOADataArrays, but by default we don't dispatch these arrays and thus these overloads are unused for default builds. It'd be a lot of unnecessary code clutter and CMake magic to determine when specific overloads would need to be ifdef'd out...it really just sounds like a big headache for nothing :) At the end of the day, these template functions are not useless (certain builds use them), there's no impact on the compiled binary (they aren't compiled unless they're used), and they're not worth fixing IMO (lots of CMake magic and preprocessor work to solve a non-problem). Allie From sean at rogue-research.com Wed Aug 16 19:06:47 2017 From: sean at rogue-research.com (Sean McBride) Date: Wed, 16 Aug 2017 19:06:47 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> Message-ID: <20170816230647.1613108841@mail.rogue-research.com> On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said: >> Allison, do you think you can work on the data array warnings? >> >> I think if both Allison and I take care of those it should whittle down the >> list to a more manageable size to start getting others to help out with. > >I think we should just disable the unused-template warnings. Most of >these cases depend on the ArrayDispatch configuration and can't be >removed without breaking features, even though some builds don't use >them. Allie, OK, so we just have to decide if we should: a) use "#pragma clang diagnostic ignored" to disable this warning for the ArrayDispatch file(s) or b) I just add -Wno-unused-template to disable it everywhere and always I guess it depends if the warning is generally useful (except for the funky case of ArrayDispatch stuff), or generally useless. 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 DLRdave at aol.com Wed Aug 16 20:37:24 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 16 Aug 2017 20:37:24 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: <20170816230647.1613108841@mail.rogue-research.com> References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> <20170816230647.1613108841@mail.rogue-research.com> Message-ID: In this thread : http://public.kitware.com/pipermail/vtk-developers/2017-August/035314.html , Ken Martin said "the llvm folks added this due to some ODR violation checking. That having it unused can cause it to be defined multiple times in a translation unit for some reason." Despite my Google skillz, I could not find what exactly he was referring to, and a search on the quoted "-Wunused-template" doesn't help much. Or I didn't dig deep enough. Anyhow: I think you should favor limiting the disabled bit of the warning to the scope where you know it's safe to ignore, and not just put a blanket suppression on it. Each warning is useful to somebody for some code, and ignoring them everywhere by a global compile flag is not the best way to suppress a warning in a handful of files among thousands. Just my opinion ... but there you have it. David C. On Wed, Aug 16, 2017 at 7:06 PM, Sean McBride wrote: > On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said: > >>> Allison, do you think you can work on the data array warnings? >>> >>> I think if both Allison and I take care of those it should whittle down the >>> list to a more manageable size to start getting others to help out with. >> >>I think we should just disable the unused-template warnings. Most of >>these cases depend on the ArrayDispatch configuration and can't be >>removed without breaking features, even though some builds don't use >>them. > > Allie, > > OK, so we just have to decide if we should: > a) use "#pragma clang diagnostic ignored" to disable this warning for the ArrayDispatch file(s) > or > b) I just add -Wno-unused-template to disable it everywhere and always > > I guess it depends if the warning is generally useful (except for the funky case of ArrayDispatch stuff), or generally useless. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > 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 richardander at yahoo.com Thu Aug 17 03:00:54 2017 From: richardander at yahoo.com (Richard Anderson) Date: Thu, 17 Aug 2017 07:00:54 +0000 (UTC) Subject: [vtk-developers] How to export vtkRenderWindow to a stl file References: <1224286491.4087536.1502953254839.ref@mail.yahoo.com> Message-ID: <1224286491.4087536.1502953254839@mail.yahoo.com> Hello,? I can export vtkRenderWindow to VMRL file. Is there any way to export it to STL file?? I did not find vtkSTLExporter. There is only vtkSTLWriter. But it does not accept vtkRenderWindow.? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Aug 17 08:59:23 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 17 Aug 2017 08:59:23 -0400 Subject: [vtk-developers] Moving generated headers in VTK Message-ID: <20170817125923.GD18506@megas.kitware.com> Hi, When using VTK from a build tree on Windows, command line lengths get out of hand quickly when linking many modules due to the fact that each module adds its own source and build directory to the list. These headers always include the export Module.h header, but sometimes other headers are generated there as well. I have this merge request: https://gitlab.kitware.com/vtk/vtk/merge_requests/3159 which changes VTK to have a single location for generated headers (and some sources due to the way vtkEncodeString works). This helps the number of include directories to go from 2n to n+1. Third party packages are skipped for now and manually add their build directories to the include path instead since they tend to write to CMAKE_CURRENT_BINARY_DIR inside of the third party packages anyways. Thoughts? --Ben From shawn.waldon at kitware.com Thu Aug 17 09:36:58 2017 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 17 Aug 2017 09:36:58 -0400 Subject: [vtk-developers] How to export vtkRenderWindow to a stl file In-Reply-To: <1224286491.4087536.1502953254839@mail.yahoo.com> References: <1224286491.4087536.1502953254839.ref@mail.yahoo.com> <1224286491.4087536.1502953254839@mail.yahoo.com> Message-ID: Hi Richard, The difference is the information the file format supports. The VRML format supports including color/textures, lighting information and most of the information about the scene. So it is an exporter given the vtkRenderWindow where that information exists and it exports the entire scene to the file. The STL file format only stores geometry, so it is a writer and should be given a single dataset as its input. If you want to export the whole scene to STL, your best path is probably to use vtkAppendPolyData to group all the data into a single dataset and connect that to the writer's input (be warned this will not get matrix transforms that are applied to the actors). HTH, Shawn On Thu, Aug 17, 2017 at 3:00 AM, Richard Anderson via vtk-developers < vtk-developers at vtk.org> wrote: > Hello, > > I can export vtkRenderWindow to VMRL file. Is there any way to export it to > STL file? > > I did not find vtkSTLExporter. There is only vtkSTLWriter. But it does not > accept vtkRenderWindow. > > Thanks, > Richard > > _______________________________________________ > 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 Thu Aug 17 09:46:30 2017 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 17 Aug 2017 09:46:30 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> <20170816230647.1613108841@mail.rogue-research.com> Message-ID: I think the warning is valuable. I do not believe it applies to general class templates that have external linkage. I believe in this case the error is specifically due to the fact the templated function in question has internal linkage. By defining it inside an anonymous namespace the templated function cannot be used anywhere else, and yet it is unused. So the compiler warns us. Potential fixes could be to - pull that struct (CheckShallowCopy) out of the anonymous namespace (I think that changes its linkage to external) - do an ifdef to remove the function for this test case - declare that function in CheckShallowCopy as extern forcing it to have external linkage I'm not 100% sure which if any of those solutions would work but that would be my guess. Maybe Sean could give one of them a shot on his system? Dave here is the llvm thread I looked at last time that talks a bit about this https://reviews.llvm.org/D29877 On Wed, Aug 16, 2017 at 8:37 PM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > In this thread : > http://public.kitware.com/pipermail/vtk-developers/2017-August/035314.html > , Ken Martin said > > "the llvm folks added this due to some ODR violation checking. > That having it unused can cause it to be defined multiple times in a > translation unit for some reason." > > Despite my Google skillz, I could not find what exactly he was > referring to, and a search on the quoted "-Wunused-template" doesn't > help much. Or I didn't dig deep enough. > > Anyhow: > > I think you should favor limiting the disabled bit of the warning to > the scope where you know it's safe to ignore, and not just put a > blanket suppression on it. Each warning is useful to somebody for some > code, and ignoring them everywhere by a global compile flag is not the > best way to suppress a warning in a handful of files among thousands. > > > Just my opinion ... but there you have it. > > David C. > > > > > > On Wed, Aug 16, 2017 at 7:06 PM, Sean McBride > wrote: > > On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said: > > > >>> Allison, do you think you can work on the data array warnings? > >>> > >>> I think if both Allison and I take care of those it should whittle > down the > >>> list to a more manageable size to start getting others to help out > with. > >> > >>I think we should just disable the unused-template warnings. Most of > >>these cases depend on the ArrayDispatch configuration and can't be > >>removed without breaking features, even though some builds don't use > >>them. > > > > Allie, > > > > OK, so we just have to decide if we should: > > a) use "#pragma clang diagnostic ignored" to disable this warning for > the ArrayDispatch file(s) > > or > > b) I just add -Wno-unused-template to disable it everywhere and always > > > > I guess it depends if the warning is generally useful (except for the > funky case of ArrayDispatch stuff), or generally useless. > > > > Cheers, > > > > -- > > ____________________________________________________________ > > Sean McBride, B. Eng sean at rogue-research.com > > Rogue Research www.rogue-research.com > > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > _______________________________________________ > > 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 Distinguished Engineer Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 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 lasso at queensu.ca Thu Aug 17 09:55:54 2017 From: lasso at queensu.ca (Andras Lasso) Date: Thu, 17 Aug 2017 13:55:54 +0000 Subject: [vtk-developers] Moving generated headers in VTK In-Reply-To: <20170817125923.GD18506@megas.kitware.com> References: <20170817125923.GD18506@megas.kitware.com> Message-ID: Thank you, this is very useful. Since VTK modularization, we have to build projects that use VTK and ITK in directories that only a few characters long (something like C:\D\Abc would work, but in C:\Dev\Abc\Def the project would fail to build). Andras -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ben Boeckel Sent: Thursday, August 17, 2017 8:59 AM To: vtk-developers at vtk.org Subject: [vtk-developers] Moving generated headers in VTK Hi, When using VTK from a build tree on Windows, command line lengths get out of hand quickly when linking many modules due to the fact that each module adds its own source and build directory to the list. These headers always include the export Module.h header, but sometimes other headers are generated there as well. I have this merge request: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F3159&data=02%7C01%7Classo%40queensu.ca%7C464ba82ecda048fa4a4208d4e56fcc0b%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636385715700219688&sdata=0hEmLR9U391LTUUjp%2F47tYWpSaaJlDMsAaiGOpkk6bc%3D&reserved=0 which changes VTK to have a single location for generated headers (and some sources due to the way vtkEncodeString works). This helps the number of include directories to go from 2n to n+1. Third party packages are skipped for now and manually add their build directories to the include path instead since they tend to write to CMAKE_CURRENT_BINARY_DIR inside of the third party packages anyways. Thoughts? --Ben _______________________________________________ Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C464ba82ecda048fa4a4208d4e56fcc0b%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636385715700219688&sdata=vPH0USoc7eEFJfzVNuhLR0s8yzNJacxMoZEkDqpRZ6Q%3D&reserved=0 Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C464ba82ecda048fa4a4208d4e56fcc0b%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636385715700219688&sdata=MsNXtZy9VEoyy0HP3nzQij4xNGxqE5W5LMME2ixFH1w%3D&reserved=0 Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C464ba82ecda048fa4a4208d4e56fcc0b%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636385715700219688&sdata=Yt19ZJaZsQucbp7YINYLMflXIMJReSzb2g9qt%2Bej%2BTM%3D&reserved=0 Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C464ba82ecda048fa4a4208d4e56fcc0b%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636385715700219688&sdata=xrvrob2lGDhRO7nXqJ0uplD5WHb6fXSZeFKoeuXZqdg%3D&reserved=0 From allison.vacanti at kitware.com Thu Aug 17 11:29:44 2017 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Thu, 17 Aug 2017 11:29:44 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> <20170816230647.1613108841@mail.rogue-research.com> Message-ID: I agree, the scope for disabling the warnings should be as small as possible -- Leave the warnings on, and then if we find one that's harmless, just push/pop the warnings around the template function. Ken pointed me at a few of these warnings a couple weeks ago and we ended up fixing a few real template resolution bugs these warnings uncovered that severely affected performance. I took a closer look through these and fixed a few harmless warnings that could be easily addressed without pragmas. See https://gitlab.kitware.com/vtk/vtk/merge_requests/3163 The vtkXMLWriter patch will probably still throw warnings after that MR is merged, but they can be safely ignored with the others. That patch just makes the optimization more robust in the case that e.g. vtkFloatArray is in the dispatch list, instead of vtkAOSDataArrayTemplate (Generic template parameters are used before the compiler will check inheritance). There were two in places I'm not familiar with, so I'll leave those for someone more familiar with these classes: Filters/General/vtkQuadraturePointsUtilities.hxx:119 Rendering/Context2D/vtkContextActor.cxx:88 The rest (overloads with AOS/SOA specific arguments) can be safely ignored. Sean, would you mind patching those? I don't have a suitable version of clang to test on so it'd probably faster if you could test locally. Most of those are in files generated from Common/Core/Testing/Cxx/TestDataArrayAPI.cxx.in, so realistically there are only a couple places that need patching. Allie On Thu, Aug 17, 2017 at 9:46 AM, Ken Martin wrote: > I think the warning is valuable. I do not believe it applies to general > class templates that have external linkage. > > I believe in this case the error is specifically due to the fact the > templated function in question has internal linkage. By defining it inside > an anonymous namespace the templated function cannot be used anywhere else, > and yet it is unused. So the compiler warns us. > > Potential fixes could be to > > - pull that struct (CheckShallowCopy) out of the anonymous namespace (I > think that changes its linkage to external) > > - do an ifdef to remove the function for this test case > > - declare that function in CheckShallowCopy as extern forcing it to have > external linkage > > I'm not 100% sure which if any of those solutions would work but that would > be my guess. Maybe Sean could give one of them a shot on his system? > > > Dave here is the llvm thread I looked at last time that talks a bit about > this > > https://reviews.llvm.org/D29877 > > > > > On Wed, Aug 16, 2017 at 8:37 PM, David Cole via vtk-developers > wrote: >> >> In this thread : >> http://public.kitware.com/pipermail/vtk-developers/2017-August/035314.html >> , Ken Martin said >> >> "the llvm folks added this due to some ODR violation checking. >> That having it unused can cause it to be defined multiple times in a >> translation unit for some reason." >> >> Despite my Google skillz, I could not find what exactly he was >> referring to, and a search on the quoted "-Wunused-template" doesn't >> help much. Or I didn't dig deep enough. >> >> Anyhow: >> >> I think you should favor limiting the disabled bit of the warning to >> the scope where you know it's safe to ignore, and not just put a >> blanket suppression on it. Each warning is useful to somebody for some >> code, and ignoring them everywhere by a global compile flag is not the >> best way to suppress a warning in a handful of files among thousands. >> >> >> Just my opinion ... but there you have it. >> >> David C. >> >> >> >> >> >> On Wed, Aug 16, 2017 at 7:06 PM, Sean McBride >> wrote: >> > On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said: >> > >> >>> Allison, do you think you can work on the data array warnings? >> >>> >> >>> I think if both Allison and I take care of those it should whittle >> >>> down the >> >>> list to a more manageable size to start getting others to help out >> >>> with. >> >> >> >>I think we should just disable the unused-template warnings. Most of >> >>these cases depend on the ArrayDispatch configuration and can't be >> >>removed without breaking features, even though some builds don't use >> >>them. >> > >> > Allie, >> > >> > OK, so we just have to decide if we should: >> > a) use "#pragma clang diagnostic ignored" to disable this warning for >> > the ArrayDispatch file(s) >> > or >> > b) I just add -Wno-unused-template to disable it everywhere and always >> > >> > I guess it depends if the warning is generally useful (except for the >> > funky case of ArrayDispatch stuff), or generally useless. >> > >> > Cheers, >> > >> > -- >> > ____________________________________________________________ >> > Sean McBride, B. Eng sean at rogue-research.com >> > Rogue Research www.rogue-research.com >> > Mac Software Developer Montr?al, Qu?bec, Canada >> > >> > >> > _______________________________________________ >> > 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 > Distinguished Engineer > Kitware Inc. > 28 Corporate Drive > Clifton Park NY 12065 > > 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 > > From bill.lorensen at gmail.com Thu Aug 17 19:30:04 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 17 Aug 2017 19:30:04 -0400 Subject: [vtk-developers] FrustumSource face ordering is wrong? Message-ID: Folks, This example colors the front and back facing polygons with yellow and red respectively. However you can see in the example that the red polygons are on the outside of the source. I have an MR that fixes the problem, but I want to be sure there is not some reason the faces are oriented the way they are now. Here is the example: https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Frustum/ Bill -- Unpaid intern in BillsBasement at noware dot com From DLRdave at aol.com Thu Aug 17 22:08:08 2017 From: DLRdave at aol.com (David Cole) Date: Thu, 17 Aug 2017 22:08:08 -0400 Subject: [vtk-developers] FrustumSource face ordering is wrong? In-Reply-To: References: Message-ID: I wonder if it's just one of those philosophical/perspective differences. If you think of the perspective view frustum, you might think of visualizing it with just 4 pieces instead of 6, leaving off the shapes for the front and back clipping planes. And then if you look at it as it goes into the screen and fades to infinity, the part you can see are the inside faces. I wonder if the original author thought of it that way and considered the inside faces the "front"... Or, it could just be an oversight. Or a bug. Or a feature. Or somebody else whose history actually goes back that far will chime in and enlighten us. :-) David C. On Thu, Aug 17, 2017 at 7:30 PM, Bill Lorensen wrote: > Folks, > > This example colors the front and back facing polygons with yellow and > red respectively. However you can see in the example that the red > polygons are on the outside of the source. > > I have an MR that fixes the problem, but I want to be sure there is > not some reason the faces are oriented the way they are now. > > Here is the example: > https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Frustum/ > > 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 > From richardander at yahoo.com Fri Aug 18 02:06:21 2017 From: richardander at yahoo.com (richard anderson) Date: Thu, 17 Aug 2017 23:06:21 -0700 (MST) Subject: [vtk-developers] What is the latest format/technology to export rendered objects in mobile device with interactiion Message-ID: <1503036381599-5744512.post@n5.nabble.com> Hello, I rendered multiple objects in a vtkRenderWindow. I would like to export them into a format which can be supported by browser or phone apps so that they can be displayed on mobile device. I would like to allow user have interactive operations, such as zoom/pan/rotate. I tried VMRL, but it seems a dated technology and few viewers are supported. Can anyone let me know what are the latest format or technology and is it supported by vtk? Thanks in advance! Richard -- View this message in context: http://vtk.1045678.n5.nabble.com/What-is-the-latest-format-technology-to-export-rendered-objects-in-mobile-device-with-interactiion-tp5744512.html Sent from the VTK - Dev mailing list archive at Nabble.com. From dave.demarle at kitware.com Fri Aug 18 08:49:49 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 18 Aug 2017 08:49:49 -0400 Subject: [vtk-developers] hypertree grid dashboard issues Message-ID: Just a note to the list to let everyone know that we are aware of and will fix the issues that the nightlies turned up today. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Fri Aug 18 09:25:03 2017 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 18 Aug 2017 09:25:03 -0400 Subject: [vtk-developers] What is the latest format/technology to export rendered objects in mobile device with interactiion In-Reply-To: <1503036381599-5744512.post@n5.nabble.com> References: <1503036381599-5744512.post@n5.nabble.com> Message-ID: For client side rendering on the web, vtk-js is the latest and greatest. https://kitware.github.io/vtk-js/index.html The project is fairly new, but is actively being developed, and it already covers a large swath of the functionality of VTK proper. For native iOS and Android, VTK's native support for OpenGLES is the way to go. David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Fri, Aug 18, 2017 at 2:06 AM, richard anderson via vtk-developers < vtk-developers at vtk.org> wrote: > Hello, > > I rendered multiple objects in a vtkRenderWindow. I would like to export > them into a format which can be supported by browser or phone apps so that > they can be displayed on mobile device. I would like to allow user have > interactive operations, such as zoom/pan/rotate. I tried VMRL, but it seems > a dated technology and few viewers are supported. > > Can anyone let me know what are the latest format or technology and is it > supported by vtk? > > Thanks in advance! > > Richard > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/What-is-the-latest-format-technology-to-export-rendered- > objects-in-mobile-device-with-interactiion-tp5744512.html > Sent from the VTK - Dev mailing list archive at Nabble.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 andy.bauer at kitware.com Fri Aug 18 10:00:50 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Fri, 18 Aug 2017 10:00:50 -0400 Subject: [vtk-developers] Various issues on my dashboards... help needed... In-Reply-To: References: <20170816133912.1633053705@mail.rogue-research.com> <20170816140121.825524940@mail.rogue-research.com> <20170816230647.1613108841@mail.rogue-research.com> Message-ID: FYI: this dashboard is looking better. I think I have all of the non-vtkDataArray template stuff taken care of in the XML writers and the flow path filters as well. I'll take a stab at the vtkPSLACReader. We have some new stuff with the vtkHyperTreeGrid changes but Dave DeMarle is actively working on that. On Thu, Aug 17, 2017 at 11:29 AM, Allie Vacanti wrote: > I agree, the scope for disabling the warnings should be as small as > possible -- Leave the warnings on, and then if we find one that's > harmless, just push/pop the warnings around the template function. Ken > pointed me at a few of these warnings a couple weeks ago and we ended > up fixing a few real template resolution bugs these warnings uncovered > that severely affected performance. > > I took a closer look through these and fixed a few harmless warnings > that could be easily addressed without pragmas. See > https://gitlab.kitware.com/vtk/vtk/merge_requests/3163 > > The vtkXMLWriter patch will probably still throw warnings after that > MR is merged, but they can be safely ignored with the others. That > patch just makes the optimization more robust in the case that e.g. > vtkFloatArray is in the dispatch list, instead of > vtkAOSDataArrayTemplate (Generic template parameters are used > before the compiler will check inheritance). > > There were two in places I'm not familiar with, so I'll leave those > for someone more familiar with these classes: > > Filters/General/vtkQuadraturePointsUtilities.hxx:119 > Rendering/Context2D/vtkContextActor.cxx:88 > > The rest (overloads with AOS/SOA specific arguments) can be safely > ignored. Sean, would you mind patching those? I don't have a suitable > version of clang to test on so it'd probably faster if you could test > locally. Most of those are in files generated from > Common/Core/Testing/Cxx/TestDataArrayAPI.cxx.in, so realistically > there are only a couple places that need patching. > > Allie > > On Thu, Aug 17, 2017 at 9:46 AM, Ken Martin > wrote: > > I think the warning is valuable. I do not believe it applies to general > > class templates that have external linkage. > > > > I believe in this case the error is specifically due to the fact the > > templated function in question has internal linkage. By defining it > inside > > an anonymous namespace the templated function cannot be used anywhere > else, > > and yet it is unused. So the compiler warns us. > > > > Potential fixes could be to > > > > - pull that struct (CheckShallowCopy) out of the anonymous namespace (I > > think that changes its linkage to external) > > > > - do an ifdef to remove the function for this test case > > > > - declare that function in CheckShallowCopy as extern forcing it to have > > external linkage > > > > I'm not 100% sure which if any of those solutions would work but that > would > > be my guess. Maybe Sean could give one of them a shot on his system? > > > > > > Dave here is the llvm thread I looked at last time that talks a bit about > > this > > > > https://reviews.llvm.org/D29877 > > > > > > > > > > On Wed, Aug 16, 2017 at 8:37 PM, David Cole via vtk-developers > > wrote: > >> > >> In this thread : > >> http://public.kitware.com/pipermail/vtk-developers/2017- > August/035314.html > >> , Ken Martin said > >> > >> "the llvm folks added this due to some ODR violation checking. > >> That having it unused can cause it to be defined multiple times in a > >> translation unit for some reason." > >> > >> Despite my Google skillz, I could not find what exactly he was > >> referring to, and a search on the quoted "-Wunused-template" doesn't > >> help much. Or I didn't dig deep enough. > >> > >> Anyhow: > >> > >> I think you should favor limiting the disabled bit of the warning to > >> the scope where you know it's safe to ignore, and not just put a > >> blanket suppression on it. Each warning is useful to somebody for some > >> code, and ignoring them everywhere by a global compile flag is not the > >> best way to suppress a warning in a handful of files among thousands. > >> > >> > >> Just my opinion ... but there you have it. > >> > >> David C. > >> > >> > >> > >> > >> > >> On Wed, Aug 16, 2017 at 7:06 PM, Sean McBride > >> wrote: > >> > On Wed, 16 Aug 2017 13:54:26 -0400, Allie Vacanti said: > >> > > >> >>> Allison, do you think you can work on the data array warnings? > >> >>> > >> >>> I think if both Allison and I take care of those it should whittle > >> >>> down the > >> >>> list to a more manageable size to start getting others to help out > >> >>> with. > >> >> > >> >>I think we should just disable the unused-template warnings. Most of > >> >>these cases depend on the ArrayDispatch configuration and can't be > >> >>removed without breaking features, even though some builds don't use > >> >>them. > >> > > >> > Allie, > >> > > >> > OK, so we just have to decide if we should: > >> > a) use "#pragma clang diagnostic ignored" to disable this warning for > >> > the ArrayDispatch file(s) > >> > or > >> > b) I just add -Wno-unused-template to disable it everywhere and > always > >> > > >> > I guess it depends if the warning is generally useful (except for the > >> > funky case of ArrayDispatch stuff), or generally useless. > >> > > >> > Cheers, > >> > > >> > -- > >> > ____________________________________________________________ > >> > Sean McBride, B. Eng sean at rogue-research.com > >> > Rogue Research www.rogue-research.com > >> > Mac Software Developer Montr?al, Qu?bec, Canada > >> > > >> > > >> > _______________________________________________ > >> > 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 > > Distinguished Engineer > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > > > 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 > > > > > _______________________________________________ > 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 sebastien.jourdain at kitware.com Fri Aug 18 10:50:17 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Fri, 18 Aug 2017 08:50:17 -0600 Subject: [vtk-developers] What is the latest format/technology to export rendered objects in mobile device with interactiion In-Reply-To: References: <1503036381599-5744512.post@n5.nabble.com> Message-ID: Hi Richard, The more modern approach to VRML would be X3D and you should be able to find/develop some web viewer based on that format. On the other hand, like Dave was mentioning we are developing vtk.js which keep the same concept as VTK which allow a natural path forward from C++/Python to JavaScript. We don't have a proper JavaScript Scene Exporter in VTK for vtk.js, but we have a ParaView macro which mostly deal with VTK classes and for which you should be able to write your own exporter either in Python or C++ in a fairly easy manner. Until we'll provide such class inside VTK proper. Some data examples and usage with code can be found here: https://kitware.github.io/vtk-js/examples/StandaloneSceneLoader.html Good luck, Seb On Fri, Aug 18, 2017 at 7:25 AM, David E DeMarle wrote: > For client side rendering on the web, vtk-js is the latest and greatest. > https://kitware.github.io/vtk-js/index.html > > The project is fairly new, but is actively being developed, and it already > covers a large swath of the functionality of VTK proper. > > For native iOS and Android, VTK's native support for OpenGLES is the way > to go. > > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 <(518)%20881-4909> > > On Fri, Aug 18, 2017 at 2:06 AM, richard anderson via vtk-developers < > vtk-developers at vtk.org> wrote: > >> Hello, >> >> I rendered multiple objects in a vtkRenderWindow. I would like to export >> them into a format which can be supported by browser or phone apps so that >> they can be displayed on mobile device. I would like to allow user have >> interactive operations, such as zoom/pan/rotate. I tried VMRL, but it >> seems >> a dated technology and few viewers are supported. >> >> Can anyone let me know what are the latest format or technology and is it >> supported by vtk? >> >> Thanks in advance! >> >> Richard >> >> >> >> -- >> View this message in context: http://vtk.1045678.n5.nabble.c >> om/What-is-the-latest-format-technology-to-export-rendered-o >> bjects-in-mobile-device-with-interactiion-tp5744512.html >> Sent from the VTK - Dev mailing list archive at Nabble.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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbopensource at gmail.com Fri Aug 18 21:14:21 2017 From: fbopensource at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Bertel?=) Date: Fri, 18 Aug 2017 21:14:21 -0400 Subject: [vtk-developers] FrustumSource face ordering is wrong? Message-ID: Hello, At the time I introduced vtkFrustumSource (2009), I used it as a tool to visualize the frustum of a spotlight as wireframe when I was working on adding shadow maps to VTK. I used it in TestShadowMapPass to make sure the two spotlights and two shadows were aligned properly. You can see the result in the following link: http://www.vtk.org/Wiki/File:TestShadowMapPass.png It did not make sense to display the frustum as a collection of opaque polygons as it would have occluded what I was trying to see (I could have used non-opaque polygons but that would have made the test more complicated). Feel free to fix the face ordering for polygon rasterization. Best, -- Fran?ois Bertel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Fri Aug 18 21:20:47 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 18 Aug 2017 21:20:47 -0400 Subject: [vtk-developers] FrustumSource face ordering is wrong? In-Reply-To: References: Message-ID: Thanks for the explanation. I think I'll leave it as is. On Aug 18, 2017 9:14 PM, "Fran?ois Bertel" wrote: > Hello, > > At the time I introduced vtkFrustumSource (2009), I used it as a tool to > visualize the frustum of a spotlight as wireframe when I was working on > adding shadow maps to VTK. I used it in TestShadowMapPass to make sure the > two spotlights and two shadows were aligned properly. You can see the > result in the following link: > > http://www.vtk.org/Wiki/File:TestShadowMapPass.png > > It did not make sense to display the frustum as a collection of opaque > polygons as it would have occluded what I was trying to see > (I could have used non-opaque polygons but that would have made the test > more complicated). > > Feel free to fix the face ordering for polygon rasterization. > > Best, > > -- > Fran?ois Bertel > > > _______________________________________________ > 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 Mon Aug 21 01:04:06 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Sun, 20 Aug 2017 23:04:06 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: I've put together an MR that uses the VTK_EXPECTS() macro to add Python safety checks to vtkPoints: https://gitlab.kitware.com/vtk/vtk/merge_requests/3176 If the point Id for GetPoint() or SetPoint() is out of range, then Python will raise an exception instead of crashing. - David On Thu, Aug 10, 2017 at 12:44 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > Den 9 aug. 2017 10:54 em skrev "David Gobbi" : > > Here's what I'm currently thinking about for wrapper hints, please let me > know if the syntax is too obtrusive. > > The basic precondition contract, similar to proposed C++ contracts: > > float GetValue(vtkIdType i) VTK_EXPECTS(i >= 0 && i < > GetNumberOfValues()); > > > This is really just a stylistic nitpick, and a matter of taste of course, > so take it or leave it, but I like it when the var is in between the > bounds, e.g. > > 0 <= i && i < GetNumberOfValues() > > As for the hint syntax, I also think what you last posted is readable > enough. > > Elvis > > > And here's the format that I'm currently thinking about for wrapper size > hints (to replace our "hints" file): > > double *GetPoint(vtkIdType i) VTK_SIZEHINT(return[3]); > > When used in combination things start to look ugly, but the method > signature is still readable: > > void SetTuple(vtkIdType i, float *a) > VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) > VTK_SIZEHINT(a[GetNumberOfComponents()]); > > float *GetTuple(vtkIdType i) > VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) > VTK_SIZEHINT(return[GetNumberOfComponents()]); > > Any thoughts? I'd really like to express the size hint as some kind of > contract, but C++ doesn't provide a way to check the number of values > pointed to by a pointer. > > As an aside: for vtkDataArray, I don't actually intend to add VTK_SIZEHINT > as shown above. Currently the size hints for vtkDataArray are hard-coded > into the wrappers, and I'll probably keep them that way in order to keep > the C++ headers clean. > > - David > > > On Mon, Aug 7, 2017 at 6:56 AM, David Gobbi wrote: > >> Hi Andras, >> >> I agree that these contracts are a better choice than inventing something >> of our own, I'm going to play around with this to see how easy it would be >> to add them to the wrappers. >> >> The macros can be made a little more compact: >> T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); >> >> Or we could use VTK_EXPECTS(i >= 0 && i < size()); >> >> - David >> >> >> >> On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso wrote: >> >>> Eventually, C++17 standard contracts may be used to specify these bounds >>> checks. For now, we may use the same format but add them as comments or >>> protected by macros; and when we switch to C++17 then these can be >>> converted to actual contracts. >>> >>> >>> >>> Proposal for contracts: http://www.open-std.org/JTC1/S >>> C22/WG21/docs/papers/2015/n4415.pdf >>> >>> >>> >>> Example contract: >>> >>> T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; >>> >>> >>> >>> For now, we could do this in VTK: >>> >>> T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); >>> >>> >>> >>> Andras >>> >>> >>> >>> >>> >>> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >>> *Sent:* Friday, August 4, 2017 4:05 PM >>> *To:* Berk Geveci >>> *Cc:* Andras Lasso ; VTK Developers < >>> vtk-developers at vtk.org> >>> *Subject:* Re: [vtk-developers] Safer item access in Python wrapped VTK >>> arrays >>> >>> >>> >>> For a while, we kicked around the idea of having the hints in the >>> comments. This would be less intrusive than adding C++11 attributes the >>> declarations (i.e. what I've been doing so far). >>> >>> >>> >>> The C++11 attributes are definitely the cleanest way for the wrappers to >>> store the hints, since the hints become part of the parse tree, so I want >>> to keep them as the primary hinting mechanism. Comment-based hints could >>> be added as a secondary mechanism, i.e. after a declaration has been parsed >>> we can check the docstring for extra hints, and then add the hints to the >>> parse tree before the wrapper code is generated. >>> >>> >>> >>> I'll have to search through the archives to remember what kind of syntax >>> we were considering for comment-based hints. >>> >>> >>> >>> - David >>> >>> >>> >>> >>> >>> On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci >>> wrote: >>> >>> As much as I support the concept of range checking in the wrappers, this >>> hint will make things look very ugly and non-standard at a time where we >>> are trying to move towards more standard looking C++. Isn't there a way of >>> doing this without mangling the signatures? >>> >>> >>> >>> On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi >>> wrote: >>> >>> Hi Andras, >>> >>> >>> >>> Yes, this would be possible. It could be hard-coded into the wrappers, >>> or even better, in the header file a generic hint could be added to the >>> index parameter so that the index would be checked against the size of the >>> array: >>> >>> >>> >>> float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); >>> >>> >>> >>> I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK >>> /Wrapping_hints >>> , >>> and I can add this "RANGECHECK" hint to the "Proposed hints" section. >>> >>> >>> >>> I'm hoping to find time to implement more of these wrapper hints over >>> the next few weeks. >>> >>> >>> >>> - David >>> >>> >>> >>> >>> >>> On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: >>> >>> Hi David, >>> >>> >>> >>> Users who mostly use VTK via Python wrapping are sometimes surprised how >>> easily they can crash the application by accessing out-of-bounds elements >>> in arrays. For example, this crashes an application: >>> >>> >>> >>> >>> a=vtk.vtkStringArray() >>> >>> >>> print(a.GetValue(0)) >>> >>> >>> >>> I first thought that it should be handled by documentation and training, >>> but it would be nicer if the wrappers could handle this. >>> >>> >>> >>> Would it be feasible to add bounds check to VTK array accessors in >>> Python wrappers, so that in case of an out of bounds access, a Python >>> exception would be raised instead of crashing the application? >>> >>> Andras >>> >>> >>> >> >> > > _______________________________________________ > 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 david.gobbi at gmail.com Wed Aug 23 08:45:45 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 23 Aug 2017 06:45:45 -0600 Subject: [vtk-developers] Safer item access in Python wrapped VTK arrays In-Reply-To: References: Message-ID: The MR is now complete, it covers vtkPoints and the vtkDataArray classes, along with vtkStringArray. https://gitlab.kitware.com/vtk/vtk/merge_requests/3176 Adding a VTK_EXPECTS(condition) check to a VTK method causes a ValueError exception to be raised if the condition is not satisfied when the method is called. There was some discussion on the MR about whether a failed index check (e.g. for GetValue(id)) should raise IndexError instead of ValueError. Since VTK_EXPECTS() is just a generic check on the parameter values, I've stuck with ValueError so far. In addition to checking index values, VTK_EXPECTS() is also used to check for NULL pointers in calls where they aren't permitted. Any comments are welcome. Cheers, - David On Sun, Aug 20, 2017 at 11:04 PM, David Gobbi wrote: > I've put together an MR that uses the VTK_EXPECTS() macro to add Python > safety checks to vtkPoints: > https://gitlab.kitware.com/vtk/vtk/merge_requests/3176 > > If the point Id for GetPoint() or SetPoint() is out of range, then Python > will raise an exception instead of crashing. > > - David > > > On Thu, Aug 10, 2017 at 12:44 AM, Elvis Stansvik < > elvis.stansvik at orexplore.com> wrote: > >> Den 9 aug. 2017 10:54 em skrev "David Gobbi" : >> >> Here's what I'm currently thinking about for wrapper hints, please let me >> know if the syntax is too obtrusive. >> >> The basic precondition contract, similar to proposed C++ contracts: >> >> float GetValue(vtkIdType i) VTK_EXPECTS(i >= 0 && i < >> GetNumberOfValues()); >> >> >> This is really just a stylistic nitpick, and a matter of taste of course, >> so take it or leave it, but I like it when the var is in between the >> bounds, e.g. >> >> 0 <= i && i < GetNumberOfValues() >> >> As for the hint syntax, I also think what you last posted is readable >> enough. >> >> Elvis >> >> >> And here's the format that I'm currently thinking about for wrapper size >> hints (to replace our "hints" file): >> >> double *GetPoint(vtkIdType i) VTK_SIZEHINT(return[3]); >> >> When used in combination things start to look ugly, but the method >> signature is still readable: >> >> void SetTuple(vtkIdType i, float *a) >> VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) >> VTK_SIZEHINT(a[GetNumberOfComponents()]); >> >> float *GetTuple(vtkIdType i) >> VTK_EXPECTS(i >= 0 && i < GetNumberOfTuples()) >> VTK_SIZEHINT(return[GetNumberOfComponents()]); >> >> Any thoughts? I'd really like to express the size hint as some kind of >> contract, but C++ doesn't provide a way to check the number of values >> pointed to by a pointer. >> >> As an aside: for vtkDataArray, I don't actually intend to add >> VTK_SIZEHINT as shown above. Currently the size hints for vtkDataArray are >> hard-coded into the wrappers, and I'll probably keep them that way in order >> to keep the C++ headers clean. >> >> - David >> >> >> On Mon, Aug 7, 2017 at 6:56 AM, David Gobbi >> wrote: >> >>> Hi Andras, >>> >>> I agree that these contracts are a better choice than inventing >>> something of our own, I'm going to play around with this to see how easy it >>> would be to add them to the wrappers. >>> >>> The macros can be made a little more compact: >>> T& operator[](size_t i) VTK_PRECONDITION(i >= 0 && i < size()); >>> >>> Or we could use VTK_EXPECTS(i >= 0 && i < size()); >>> >>> - David >>> >>> >>> >>> On Fri, Aug 4, 2017 at 7:39 PM, Andras Lasso wrote: >>> >>>> Eventually, C++17 standard contracts may be used to specify these >>>> bounds checks. For now, we may use the same format but add them as comments >>>> or protected by macros; and when we switch to C++17 then these can be >>>> converted to actual contracts. >>>> >>>> >>>> >>>> Proposal for contracts: http://www.open-std.org/JTC1/S >>>> C22/WG21/docs/papers/2015/n4415.pdf >>>> >>>> >>>> >>>> Example contract: >>>> >>>> T& operator[](size_t i) [[expects: i >= 0 && i < size()]]; >>>> >>>> >>>> >>>> For now, we could do this in VTK: >>>> >>>> T& operator[](size_t i) VTK_CONTRACT([[expects: i >= 0 && i < size()]]); >>>> >>>> >>>> >>>> Andras >>>> >>>> >>>> >>>> >>>> >>>> *From:* David Gobbi [mailto:david.gobbi at gmail.com] >>>> *Sent:* Friday, August 4, 2017 4:05 PM >>>> *To:* Berk Geveci >>>> *Cc:* Andras Lasso ; VTK Developers < >>>> vtk-developers at vtk.org> >>>> *Subject:* Re: [vtk-developers] Safer item access in Python wrapped >>>> VTK arrays >>>> >>>> >>>> >>>> For a while, we kicked around the idea of having the hints in the >>>> comments. This would be less intrusive than adding C++11 attributes the >>>> declarations (i.e. what I've been doing so far). >>>> >>>> >>>> >>>> The C++11 attributes are definitely the cleanest way for the wrappers >>>> to store the hints, since the hints become part of the parse tree, so I >>>> want to keep them as the primary hinting mechanism. Comment-based hints >>>> could be added as a secondary mechanism, i.e. after a declaration has been >>>> parsed we can check the docstring for extra hints, and then add the hints >>>> to the parse tree before the wrapper code is generated. >>>> >>>> >>>> >>>> I'll have to search through the archives to remember what kind of >>>> syntax we were considering for comment-based hints. >>>> >>>> >>>> >>>> - David >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Aug 4, 2017 at 1:30 PM, Berk Geveci >>>> wrote: >>>> >>>> As much as I support the concept of range checking in the wrappers, >>>> this hint will make things look very ugly and non-standard at a time where >>>> we are trying to move towards more standard looking C++. Isn't there a way >>>> of doing this without mangling the signatures? >>>> >>>> >>>> >>>> On Fri, Aug 4, 2017 at 1:06 PM, David Gobbi >>>> wrote: >>>> >>>> Hi Andras, >>>> >>>> >>>> >>>> Yes, this would be possible. It could be hard-coded into the wrappers, >>>> or even better, in the header file a generic hint could be added to the >>>> index parameter so that the index would be checked against the size of the >>>> array: >>>> >>>> >>>> >>>> float GetValue(vtkIdType idx VTK_RANGECHECK(0,GetNumberOfValues())); >>>> >>>> >>>> >>>> I have a list of wrapper hints at http://www.vtk.org/Wiki/VTK >>>> /Wrapping_hints >>>> , >>>> and I can add this "RANGECHECK" hint to the "Proposed hints" section. >>>> >>>> >>>> >>>> I'm hoping to find time to implement more of these wrapper hints over >>>> the next few weeks. >>>> >>>> >>>> >>>> - David >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Aug 4, 2017 at 9:53 AM, Andras Lasso wrote: >>>> >>>> Hi David, >>>> >>>> >>>> >>>> Users who mostly use VTK via Python wrapping are sometimes surprised >>>> how easily they can crash the application by accessing out-of-bounds >>>> elements in arrays. For example, this crashes an application: >>>> >>>> >>>> >>>> >>> a=vtk.vtkStringArray() >>>> >>>> >>> print(a.GetValue(0)) >>>> >>>> >>>> >>>> I first thought that it should be handled by documentation and >>>> training, but it would be nicer if the wrappers could handle this. >>>> >>>> >>>> >>>> Would it be feasible to add bounds check to VTK array accessors in >>>> Python wrappers, so that in case of an out of bounds access, a Python >>>> exception would be raised instead of crashing the application? >>>> >>>> Andras >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> 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 pdhahn at compintensehpc.com Sat Aug 26 12:47:30 2017 From: pdhahn at compintensehpc.com (pdhahn) Date: Sat, 26 Aug 2017 09:47:30 -0700 (MST) Subject: [vtk-developers] Request: Make certain methods related to tick labels in vtkAxis virtual Message-ID: <1503766050439-5744594.post@n5.nabble.com> Please make the following "generate" methods related to tick labels in vtkAxis virtual so they can be overridden in a subclass: GenerateSimpleLabel(), GenerateSprintfLabel(), GenerateLabelFormat(), GenerateLogSpacedLinearTicks() These methods all can call this->TickLabels->InsertNextValue( ... ) with a label that they create. This would allow better control over tick label generation by re-implementing these in a subclass that handles additional kinds of "notation" and corresponding tick labels, as opposed to having to use the custom tick labels mechanism. In particular, date-time (timestamp) tick labels. -- View this message in context: http://vtk.1045678.n5.nabble.com/Request-Make-certain-methods-related-to-tick-labels-in-vtkAxis-virtual-tp5744594.html Sent from the VTK - Dev mailing list archive at Nabble.com. From pdhahn at compintensehpc.com Sat Aug 26 12:53:00 2017 From: pdhahn at compintensehpc.com (pdhahn) Date: Sat, 26 Aug 2017 09:53:00 -0700 (MST) Subject: [vtk-developers] Request: Make certain methods related to tooltip labels in vtkPlot virtual Message-ID: <1503766380658-5744595.post@n5.nabble.com> Please make the method GetNumber() in vtkPlot virtual so it can be overridden in a subclass. This would allow better control over tooltip label generation by re-implementing it in a subclass that handles additional kinds of "notation" and corresponding labels for the given axis. In particular, date-time (timestamp) labels. -- View this message in context: http://vtk.1045678.n5.nabble.com/Request-Make-certain-methods-related-to-tooltip-labels-in-vtkPlot-virtual-tp5744595.html Sent from the VTK - Dev mailing list archive at Nabble.com. From andy.bauer at kitware.com Sat Aug 26 16:47:33 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Sat, 26 Aug 2017 16:47:33 -0400 Subject: [vtk-developers] Request: Make certain methods related to tooltip labels in vtkPlot virtual In-Reply-To: <1503766380658-5744595.post@n5.nabble.com> References: <1503766380658-5744595.post@n5.nabble.com> Message-ID: Hi, Feel free to add that change into VTK yourself. There are developer instructions at https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md that can help guide you through the process. Best, Andy On Sat, Aug 26, 2017 at 12:53 PM, pdhahn wrote: > Please make the method GetNumber() in vtkPlot virtual so it can be > overridden > in a subclass. > > This would allow better control over tooltip label generation by > re-implementing it in a subclass that handles additional kinds of > "notation" > and corresponding labels for the given axis. In particular, date-time > (timestamp) labels. > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/Request-Make-certain-methods-related-to-tooltip- > labels-in-vtkPlot-virtual-tp5744595.html > Sent from the VTK - Dev mailing list archive at Nabble.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 andy.bauer at kitware.com Sat Aug 26 16:47:50 2017 From: andy.bauer at kitware.com (Andy Bauer) Date: Sat, 26 Aug 2017 16:47:50 -0400 Subject: [vtk-developers] Request: Make certain methods related to tick labels in vtkAxis virtual In-Reply-To: <1503766050439-5744594.post@n5.nabble.com> References: <1503766050439-5744594.post@n5.nabble.com> Message-ID: Hi, Feel free to add that change into VTK yourself. There are developer instructions at https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md that can help guide you through the process. Best, Andy On Sat, Aug 26, 2017 at 12:47 PM, pdhahn wrote: > Please make the following "generate" methods related to tick labels in > vtkAxis virtual so they can be overridden in a subclass: > > GenerateSimpleLabel(), GenerateSprintfLabel(), GenerateLabelFormat(), > GenerateLogSpacedLinearTicks() > > These methods all can call this->TickLabels->InsertNextValue( ... ) with > a > label that they create. > > This would allow better control over tick label generation by > re-implementing these in a subclass that handles additional kinds of > "notation" and corresponding tick labels, as opposed to having to use the > custom tick labels mechanism. In particular, date-time (timestamp) tick > labels. > > > > > -- > View this message in context: http://vtk.1045678.n5.nabble. > com/Request-Make-certain-methods-related-to-tick- > labels-in-vtkAxis-virtual-tp5744594.html > Sent from the VTK - Dev mailing list archive at Nabble.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 Tue Aug 29 14:41:27 2017 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 29 Aug 2017 14:41:27 -0400 Subject: [vtk-developers] Request for comment: New VTK Examples and doxygen pages Message-ID: Folks, The new (former wiki) examples is getting some decent traffic. https://lorensen.github.io/VTKExamples/site/ The new examples have a custom search so a user can type a class name and get all examples that use that class (it is a custom google search engine). I wonder if we should consider including these examples in: http://www.vtk.org/doc/nightly/html/pages.html There are currently over 800 c++ examples and over 140 python examples. Maybe there are too many and they might overload the system. The current page generator is written in perl so I can't be pf any help... Thoughts? Bill -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Tue Aug 29 15:09:13 2017 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 29 Aug 2017 15:09:13 -0400 Subject: [vtk-developers] Request for comment: New VTK Examples and doxygen pages In-Reply-To: References: Message-ID: +1 many folks learn from examples best let's help them! On Tue, Aug 29, 2017 at 2:41 PM, Bill Lorensen wrote: > Folks, > > The new (former wiki) examples is getting some decent traffic. > https://lorensen.github.io/VTKExamples/site/ > > The new examples have a custom search so a user can type a class name > and get all examples that use that class (it is a custom google search > engine). > > I wonder if we should consider including these examples in: > http://www.vtk.org/doc/nightly/html/pages.html > > There are currently over 800 c++ examples and over 140 python > examples. Maybe there are too many and they might overload the system. > > The current page generator is written in perl so I can't be pf any help... > > Thoughts? > > 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 > > -- William J. Schroeder, PhD Kitware, Inc. - Building the World's Technical Computing Software 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Aug 30 14:44:22 2017 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 30 Aug 2017 12:44:22 -0600 Subject: [vtk-developers] Hints for Python wrappers Message-ID: Hi All, The MR for the VTK_EXPECTS hint is ready to merge. To refresh your memory, this hint adds preconditions to VTK methods so that users are less likely to cause a segfault when they call VTK from a Python script or console: void SetTuple(vtkIdType tupleIdx, const double* tuple) VTK_EXPECTS(0 <= tupleIdx && tupleIdx < GetNumberOfTuples()); It is also used to check for null pointers. Really, it can be check anything to do with the state of the object or the method args, as long as the information is available though the public API. Failed checks cause a ValueError exception to be raised (which is, of course, much better than a segfault). The next hint to be added will be VTK_SIZEHINT(), which is documented here: http://www.vtk.org/Wiki/VTK/Wrapping_hints After some thought, I've decided that the cleanest place to add this hint is after the method declaration: double* GetPoint() VTK_SIZEHINT(3); The hint takes one or two arguments. With two arguments, the first arg is the name of the parameter to which the hint applies. The second argument (the 'size') can be any C++ expression that evaluates to an integral type. For example: void SetTuple(const double* tuple) VTK_SIZEHINT(tuple, GetNumberOfComponents()); void InsertNextCell(vtkIdType n, vtkidType* ptIds) VTK_SIZEHINT(ptIds, n); Since VTK_SIZEHINT is a variadic macro, it formally requires C++11, but compilers have supported variadic macros for a very, very long time so I don't expect this to be an issue. Probably the most important use of VTK_SIZEHINT will be by people who wrap their own VTK classes but who don't want to mess around with VTK's hints file. Some general info about hints: - Any number of hints is allowed for a method. Hints are applied in the order in which they appear. - Hints are inherited. If you add a hint to a base class method, then the same hint applies to all methods that override the base class method. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Wed Aug 30 17:45:12 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 30 Aug 2017 17:45:12 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server Message-ID: Hi all, I am trying to run https://kitware.github.io/paraviewweb/examples/RemoteRenderer.html With VTK as a server. I would like that no window is opened on the server. I tried setting renderWindow.OffScreenRenderingOn() in vtk_web_cone.py however this does not work. A window (black) will still be created by the renderWindowInteractor, even if the rendering will happen offscreen. It seems that the interactor is used to send events back to the client, but maybe it also believes that it has to forward events from the window. Do you have any suggestions for making this work? Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Wed Aug 30 17:50:37 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Wed, 30 Aug 2017 15:50:37 -0600 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: Are you using "vtkpython" of "pvpython/pvbatch" ? If you use pvbatch, that should work out of the box with PV_ALLOW_BATCH_INTERACTION=1. If you use python/vtkpython, you should create the correct vtkRenderWindow class that is offscreen. Hope this helps, Seb On Wed, Aug 30, 2017 at 3:45 PM, Dan Lipsa wrote: > Hi all, > I am trying to run > https://kitware.github.io/paraviewweb/examples/RemoteRenderer.html > > With VTK as a server. I would like that no window is opened on the server. > > I tried setting > renderWindow.OffScreenRenderingOn() > in vtk_web_cone.py > however this does not work. A window (black) will still be created by > the renderWindowInteractor, even if the rendering will happen offscreen. > > It seems that the interactor is used to send events back to the client, > but maybe it also believes that it has to forward events from the window. > > Do you have any suggestions for making this work? > > Thanks, > Dan > > > _______________________________________________ > 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 dan.lipsa at kitware.com Thu Aug 31 09:45:24 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 31 Aug 2017 09:45:24 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: Hi Seb, On Wed, Aug 30, 2017 at 5:50 PM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > Are you using "vtkpython" of "pvpython/pvbatch" ? > vtkpython. > If you use python/vtkpython, you should create the correct vtkRenderWindow > class that is offscreen. > > Are you talking about vtkEGLRenderWindow or vtkOSOpenGLRenderWindow? What if those are not available? I am trying to set renderWindow.OffScreenRenderingOn() This partially works, in that rendering happens offscreen, but a blank window is still created by the render window interactor. Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankhesh.jhaveri at kitware.com Thu Aug 31 10:24:06 2017 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Thu, 31 Aug 2017 14:24:06 +0000 Subject: [vtk-developers] Announce: vtk 8.0.1 released! Message-ID: The VTK maintenance team is happy to announce a new patch release for VTK 8.0. You can find the source, data and documentation tarballs here: http://www.vtk.org/download See detailed release notes on the Kitware blog: https://blog.kitware.com/vtk-8-0-1-released/ Please try this version of VTK and report any issues to the list or the bug tracker . We hope you enjoy this release of VTK! As always, contact Kitware and the mailing lists for assistance. Thanks, VTK Maintenance Team ? -- Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware | (518) 881-4417 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Thu Aug 31 10:24:49 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 31 Aug 2017 08:24:49 -0600 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: Hi Dan, Yes I'm talking about those vtkEGLRenderWindow or vtkOSOpenGLRenderWindow. Regarding what you are doing with OffScreenRenderingOn(), you are seeing exactly what is expected... The Window will always show... Seb On Thu, Aug 31, 2017 at 7:45 AM, Dan Lipsa wrote: > Hi Seb, > > On Wed, Aug 30, 2017 at 5:50 PM, Sebastien Jourdain < > sebastien.jourdain at kitware.com> wrote: > >> Are you using "vtkpython" of "pvpython/pvbatch" ? >> > > vtkpython. > > >> If you use python/vtkpython, you should create the correct >> vtkRenderWindow class that is offscreen. >> >> > Are you talking about vtkEGLRenderWindow or vtkOSOpenGLRenderWindow? What > if those are not available? > > I am trying to set > renderWindow.OffScreenRenderingOn() > This partially works, in that rendering happens offscreen, but a blank > window is still created by the render window interactor. > > Thanks, > Dan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Thu Aug 31 10:47:05 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 31 Aug 2017 10:47:05 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: > > Regarding what you are doing with OffScreenRenderingOn(), you are seeing > exactly what is expected... The Window will always show... > Is there a specific reason why that is the case? I would want the behaviour of ParaView's pvserver which does not show anything on the screen. I just tried the RemoteServer example through 'pvpython pv_server.py -p 1234' and I see the same behaviour: rendering happens offscreen but a blank window still shows. Thanks, Dan > Seb > > On Thu, Aug 31, 2017 at 7:45 AM, Dan Lipsa wrote: > >> Hi Seb, >> >> On Wed, Aug 30, 2017 at 5:50 PM, Sebastien Jourdain < >> sebastien.jourdain at kitware.com> wrote: >> >>> Are you using "vtkpython" of "pvpython/pvbatch" ? >>> >> >> vtkpython. >> >> >>> If you use python/vtkpython, you should create the correct >>> vtkRenderWindow class that is offscreen. >>> >>> >> Are you talking about vtkEGLRenderWindow or vtkOSOpenGLRenderWindow? What >> if those are not available? >> >> I am trying to set >> renderWindow.OffScreenRenderingOn() >> This partially works, in that rendering happens offscreen, but a blank >> window is still created by the render window interactor. >> >> Thanks, >> Dan >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Thu Aug 31 11:20:23 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 31 Aug 2017 09:20:23 -0600 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: And then if you use pvbatch instead of pvpython, that window disappear the way you want... There are many reasons why that's the case but mostly history. What ParaView is doing is figuring out at runtime which render window it should instantiate. Since you are not in ParaView, you have to implement that logic yourself. On Thu, Aug 31, 2017 at 8:47 AM, Dan Lipsa wrote: > > >> Regarding what you are doing with OffScreenRenderingOn(), you are seeing >> exactly what is expected... The Window will always show... >> > > > Is there a specific reason why that is the case? I would want the > behaviour of ParaView's pvserver which does not show anything on the screen. > > I just tried the RemoteServer example through 'pvpython pv_server.py -p > 1234' and I see the same behaviour: rendering happens offscreen but a blank > window still shows. > > > Thanks, > Dan > > > > >> Seb >> >> On Thu, Aug 31, 2017 at 7:45 AM, Dan Lipsa wrote: >> >>> Hi Seb, >>> >>> On Wed, Aug 30, 2017 at 5:50 PM, Sebastien Jourdain < >>> sebastien.jourdain at kitware.com> wrote: >>> >>>> Are you using "vtkpython" of "pvpython/pvbatch" ? >>>> >>> >>> vtkpython. >>> >>> >>>> If you use python/vtkpython, you should create the correct >>>> vtkRenderWindow class that is offscreen. >>>> >>>> >>> Are you talking about vtkEGLRenderWindow or vtkOSOpenGLRenderWindow? >>> What if those are not available? >>> >>> I am trying to set >>> renderWindow.OffScreenRenderingOn() >>> This partially works, in that rendering happens offscreen, but a blank >>> window is still created by the render window interactor. >>> >>> Thanks, >>> Dan >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Thu Aug 31 11:30:59 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 31 Aug 2017 11:30:59 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: On Thu, Aug 31, 2017 at 11:20 AM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > And then if you use pvbatch instead of pvpython, that window disappear the > way you want... > While this works to show the cone on the client, it crashes when you try to interact with it. I've seen the same behavior for the VTK server if you don't set the interactor at all. There are many reasons why that's the case but mostly history. What > ParaView is doing is figuring out at runtime which render window it should > instantiate. > Since you are not in ParaView, you have to implement that logic yourself. > I think it chooses different render windows only if EGL or OSMesa are available. Otherwise it just sets OffScreenRenderingOn(). I'll dig to see what else it does so that no window shows. Thanks Seb. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastien.jourdain at kitware.com Thu Aug 31 11:35:51 2017 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Thu, 31 Aug 2017 09:35:51 -0600 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: The solution was in my first email => If you use pvbatch, that should work out of the box with PV_ALLOW_BATCH_ INTERACTION=1. For the window part ask Utkarsh since he did that work a couple weeks ago on ParaView... On Thu, Aug 31, 2017 at 9:30 AM, Dan Lipsa wrote: > On Thu, Aug 31, 2017 at 11:20 AM, Sebastien Jourdain < > sebastien.jourdain at kitware.com> wrote: > >> And then if you use pvbatch instead of pvpython, that window disappear >> the way you want... >> > > While this works to show the cone on the client, it crashes when you try > to interact with it. I've seen the same > behavior for the VTK server if you don't set the interactor at all. > > > There are many reasons why that's the case but mostly history. What >> ParaView is doing is figuring out at runtime which render window it should >> instantiate. >> Since you are not in ParaView, you have to implement that logic yourself. >> > > I think it chooses different render windows only if EGL or OSMesa are > available. Otherwise it just sets OffScreenRenderingOn(). I'll dig to see > what else it does so that no window shows. > > Thanks Seb. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Aug 31 11:53:27 2017 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 31 Aug 2017 11:53:27 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: > For the window part ask Utkarsh since he did that work a couple weeks ago on > ParaView... See: [1] https://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/Offscreen.html [2] https://gitlab.kitware.com/paraview/paraview/blob/master/ParaViewCore/ClientServerCore/Rendering/vtkPVSynchronizedRenderWindows.cxx#L59-114 From dan.lipsa at kitware.com Thu Aug 31 12:03:08 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 31 Aug 2017 12:03:08 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: On Thu, Aug 31, 2017 at 11:35 AM, Sebastien Jourdain < sebastien.jourdain at kitware.com> wrote: > The solution was in my first email > > => If you use pvbatch, that should work out of the box with > PV_ALLOW_BATCH_INTERACTION=1. > Nice! This does work. Sorry, I missed this. > > For the window part ask Utkarsh since he did that work a couple weeks ago > on ParaView... > > On Thu, Aug 31, 2017 at 9:30 AM, Dan Lipsa wrote: > >> On Thu, Aug 31, 2017 at 11:20 AM, Sebastien Jourdain < >> sebastien.jourdain at kitware.com> wrote: >> >>> And then if you use pvbatch instead of pvpython, that window disappear >>> the way you want... >>> >> >> While this works to show the cone on the client, it crashes when you try >> to interact with it. I've seen the same >> behavior for the VTK server if you don't set the interactor at all. >> >> >> There are many reasons why that's the case but mostly history. What >>> ParaView is doing is figuring out at runtime which render window it should >>> instantiate. >>> Since you are not in ParaView, you have to implement that logic yourself. >>> >> >> I think it chooses different render windows only if EGL or OSMesa are >> available. Otherwise it just sets OffScreenRenderingOn(). I'll dig to see >> what else it does so that no window shows. >> >> Thanks Seb. >> >> Dan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Thu Aug 31 15:27:07 2017 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 31 Aug 2017 15:27:07 -0400 Subject: [vtk-developers] VTK Web with no window opened by the VTK server In-Reply-To: References: Message-ID: Hi all, The solution is to replace: - renderWindowInteractor = vtk.vtkRenderWindowInteractor() with + renderWindow.OffScreenRenderingOn() + renderWindowInteractor = vtk.vtkGenericRenderWindowInteractor() The problem was that vtkRenderWindowInteractor created a window to read events from. Thanks Seb and Utkarsh for your help. Dan On Thu, Aug 31, 2017 at 12:03 PM, Dan Lipsa wrote: > > > On Thu, Aug 31, 2017 at 11:35 AM, Sebastien Jourdain < > sebastien.jourdain at kitware.com> wrote: > >> The solution was in my first email >> >> => If you use pvbatch, that should work out of the box with >> PV_ALLOW_BATCH_INTERACTION=1. >> > > Nice! This does work. Sorry, I missed this. > > > >> >> For the window part ask Utkarsh since he did that work a couple weeks ago >> on ParaView... >> >> On Thu, Aug 31, 2017 at 9:30 AM, Dan Lipsa wrote: >> >>> On Thu, Aug 31, 2017 at 11:20 AM, Sebastien Jourdain < >>> sebastien.jourdain at kitware.com> wrote: >>> >>>> And then if you use pvbatch instead of pvpython, that window disappear >>>> the way you want... >>>> >>> >>> While this works to show the cone on the client, it crashes when you try >>> to interact with it. I've seen the same >>> behavior for the VTK server if you don't set the interactor at all. >>> >>> >>> There are many reasons why that's the case but mostly history. What >>>> ParaView is doing is figuring out at runtime which render window it should >>>> instantiate. >>>> Since you are not in ParaView, you have to implement that logic >>>> yourself. >>>> >>> >>> I think it chooses different render windows only if EGL or OSMesa are >>> available. Otherwise it just sets OffScreenRenderingOn(). I'll dig to see >>> what else it does so that no window shows. >>> >>> Thanks Seb. >>> >>> Dan >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: