From mathieu.malaterre at gmail.com Tue Sep 1 06:22:29 2015 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Tue, 1 Sep 2015 12:22:29 +0200 Subject: [vtk-developers] =?utf-8?q?Status_of_GCC=5FXML_=E2=86=92_CableSwi?= =?utf-8?q?g_=E2=86=92_mummy_=E2=86=92_Activiz=2ENET_vs_CastXML?= Message-ID: [long time no post] Hi there, Short version: What is the status of Activiz.NET ? --- Long version: 1. GCC_XML is dead and has been replaced by CastXML ( http://gccxml.github.io/HTML/Index.html) 2. GCC_XML does not compile with GCC-5, https://bugs.debian.org/792280 3. mummy depends on GCC_XML (at least with minimal kwsys interaction) 4. CableSwig depends on GCC_XML 5. Activiz.NET depends on GCC_XML and mummy Is there a transition plan GCC_XML ? CastXML for the above Activiz.NET dependencies ? I've not seen much activities neither on mummy nor on CableSwig. Some recent commmits on Activiz.NET make it appears as if it works with VTK 6.1. Thanks much for clarification, -- Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Tue Sep 1 07:16:17 2015 From: julien.jomier at kitware.com (Julien Jomier) Date: Tue, 1 Sep 2015 13:16:17 +0200 Subject: [vtk-developers] =?utf-8?q?Status_of_GCC=5FXML_=E2=86=92_CableSwi?= =?utf-8?q?g_=E2=86=92_mummy_=E2=86=92_Activiz=2ENET_vs_CastXML?= In-Reply-To: References: Message-ID: <55E58901.2090705@kitware.com> Mathieu, Currently ActiViz.NET is maintained to support the latest releases of VTK, but will only compile with GCC_XML. We have started the replacement of GCC_XML with CastXML. I hope that will be able to finish it soon, but currently cannot tell you a specific date. Julien On 01/09/2015 12:22, Mathieu Malaterre wrote: > [long time no post] > > Hi there, > > Short version: What is the status of Activiz.NET ? > > --- > > Long version: > > 1. GCC_XML is dead and has been replaced by CastXML > (http://gccxml.github.io/HTML/Index.html) > 2. GCC_XML does not compile with GCC-5, https://bugs.debian.org/792280 > 3. mummy depends on GCC_XML (at least with minimal kwsys interaction) > 4. CableSwig depends on GCC_XML > 5. Activiz.NET depends on GCC_XML and mummy > > Is there a transition plan GCC_XML ? CastXML for the above Activiz.NET > dependencies ? I've not seen much activities neither on mummy nor on > CableSwig. Some recent commmits on Activiz.NET make it appears as if it > works with VTK 6.1. > > Thanks much for clarification, > -- > Mathieu > > > _______________________________________________ > 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 brudfors at hggm.es Thu Sep 3 09:22:41 2015 From: brudfors at hggm.es (Mikael Brudfors) Date: Thu, 3 Sep 2015 15:22:41 +0200 Subject: [vtk-developers] vtkImplicitPolyDataDistance: coordinates of nearest point Message-ID: <55E849A1.5060002@hggm.es> Hello all, Using vtkImplicitPolyDataDistance to compute the distance from a point x to the nearest point p, on an input vtkPolyData, I can get the distance by calling EvaluateFunction(...). Is there also a way to get the coordinates of the point p? Thank you, Mikael From ken.martin at kitware.com Thu Sep 3 10:22:48 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 3 Sep 2015 10:22:48 -0400 Subject: [vtk-developers] Time for some more OpenGL2 Polygonal Updates Message-ID: Heya folks, giving an update on some recent changes/features in the OpenGL2 backend. Here we go... 1) *SHADOW SUPPORT* - Added support for shadows back into VTK and changed it up a bit. Shadows can provide valuable depth queues and structural queues in many domains such as surgical simulation, CFD analysis, and surgical planning. You can now turn on shadows in VTK by simply doing renderer->UseShadowsOn() (wow dude that?s easy) Having said that, remember that the default light in VTK is a headlight and a headlight doesn?t really produce any shadows (ahh there?s the catch). So if you want shadows make sure to have a light that is a scene light for best performance or a camera light. There is an example/test in Rendering/OpenGL2/Testing/Cxx/TestShadowMapPass.cxx. That example sets up Shadows using render passes which allows for a bit more flexibility but the same approach is implemented under the hood in renderer->UseShadowsOn() 2) *CUSTOM SHADERS* - Added support for customizing the default PolyDataMapper shaders. You can now modify or completely replace the default VTK shaders using methods such as AddShaderReplacement: replaces a strings in the current shader SetVertexShaderCode: replaces the default shader template with your own AddObserver(vtkCommand::UpdateShaderEvent,...) These methods (and similar others) give you a great degree on control of the VTK PolyData shaders. There are examples/tests in Rendering/OpenGL2/Testing/Cxx/TestUserShader.cxx and TestUserShader2.cxx. Through the UpdateShaderEvent you can modify the default VTK uniforms or your own uniforms as desired. There is currently not a general purpose easy API for binding your own data arrays to attributes but we may add one at some point in the future. Currently VTK will send down the default attributes for you to use in your shader (position, normal, tcoords, colors, etc) 3) *IMPROVED POINT SPRITES* - Significantly improved the vtkPointGaussianMapper. With some great help from Scott Wittenburg and Sebastien Jourdain we added the ability to map size and/or opacity arrays through a vtkPiecewiseFunction so that very large or small data can be rendered in a very flexible manner. We also made it so that if you do provide a cell array with an explicit list of points to use, then the mapper will use only those points, and finally you can modify the fragment shader code on the mapper now to draw whatever shapes you want. There is a new example/test in Rendering/OpenGL2/Testing/Cxx/TestPointGaussianMapperOpacity.cxx that shows using the new features and includes sample shader code for drawing squares or black edged circles. 4) *ANDROID and iOS IMPROVEMENTS* - Revisited the android VTK build with some help from Casey Goodlett and finally added two nightly android dashboards for VTK. One for API 18 with OpenGL ES 2.0 and one for API 21 with OpenGL ES 3.0. This should help us maintain working builds for Android going forward. While we were at it we added the vtkFrameBufferObject and ShadowMap functionality into the OpenGL ES builds so that those devices can make use of that functionality. We are still working on the android build process and hope to someday soon put out some binaries to make using VTK on android even easier. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* Ken Martin [mailto:ken.martin at kitware.com] *Sent:* Wednesday, July 15, 2015 3:19 PM *To:* 'vtkdev' *Subject:* RE: Some OpenGL2 Polygonal Updates etc It has been a while and I am overdue for updates on the new OpenGL rendering engine. We are in pretty good shape in terms of the new rendering engine with VTK. Tests are passing and we are generally ready to make it the default for the upcoming VTK release. The old engine will also be available as a CMake option. Here are some specific changes since the last update. 1) Added support in the PointGaussianMapper for rendering points as points ( /golfclap ). Sometimes in cosmology distant regions will be rendered as points while closer regions are rendered as splats. Now this mapper can handle both cases. This also makes this mapper an efficient mapper in VTK for rendering point clouds. It will render vtkPoints with colors quickly and with minimal memory. 2) Moved the new backend to OpenGL 3.2. While it still should mostly work with OpenGL 2.1 our target version is 3.2 which adds some nice features and yet is still fairly old. One of the big additions is support for geometry shaders. VTK now supports the use of geometry shaders and vtkOpenGLPolyDataMapper has some features to help make writing a geometry shader easier for all the numerous rendering cases VTK supports. 3) One of the features OpenGL 3.2 does not always support is rendering thick lines. The spec only requires support for thicknesses up to 1.0. So we have implemented support in VTK using a geometry shader for thick lines on systems that do not support them. 4) Had a chance to work with the Mesa folks to fix an issue in Mesa that was causing problems with cell coloring and picking. They were great to work with and as of Mesa version 10.5.5 this is fixed. 5) Made a large change to how cell coloring and picking was handled. In the old OpenGL2 code we would duplicate vertices to handle cell coloring so that each vertex was only used by one cell. This caused a huge explosion in memory required for those cases. The new approach makes use of gl_PrimitiveID to lookup cell colors (or cell normals or pick ids) in a texture map which saves us from having to duplicate vertices. Unfortunately gl_PrimitiveID is buggy on current Apple systems with AMD hardware so we had to implement a workaround for those systems which does impact performance on those systems. Apple is aware of the issue and will hopefully have a fix in the future. 6) Many fixes to vtkCompositePolyDataMapper2 to handle complex cases that ParaView testing exposed. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* Ken Martin [mailto:ken.martin at kitware.com ] *Sent:* Monday, February 2, 2015 11:26 AM *To:* 'vtkdev' *Subject:* Some OpenGL2 Polygonal Updates etc Here are a few updates to the polygonal work we?ve been doing on the new OpenGL2 backend in VTK. 1) Created a vtkPointGaussianMapper [3] class for cosmology for quickly rendering lots of translucent Gaussian splats. This class will get refined a bit as it starts getting used more. Similar in concept to the PointSprite extensions that were added into Paraview by John Biddiscombe, Ugo Varetto and Stephane Ploix from CSCS and EDF. 2) Changed how the transformation matrices were handled in the vertex shader [7]. It was doing V? = VCDC * MCVC * V and a couple tests were failing. Instead we now compute MCDC on the CPU in double precision and instead do V? = MCDC * V in the shader which fixed the test and is generally a better way to do it. We often need the other two matrices as well which is why the original code just used those. 3) Added a rendering timing framework/executable [5] to make it easier to run test sequences across machines and see the results. Marcus and Rob have expanded on it and Aashish has added a volume rendering test. 4) Rewrote the vtkParametricFunctionSource [6] to be significantly faster (4x) and more memory efficient. We use this source to generate surfaces for rendering timings and it was a bit slow. 5) A bunch of fixes related to getting IceT to work with OpenGL2 [1] which led to some release graphics resource issues being fixed [2]. 6) ?Fixed? a longstanding failing test, TestChartXYZ [4] which was intermittently failing on some systems. 7) Marcus and Rob ran some rendering benchmarks showing upwards of 3 billion triangles per second on a 300 million triangle model. That is a big model and some solid performance. Currently I am wrapping up a change to the vtkCompositePolyDataMapper2 so that in some common circumstances it will render significantly faster (maybe 10x). This is targeted at helping apps that have lots of small polygonal parts that are not glyphed. Also adding in support for texture coordinate transformation matrices which are used by the GeoView classes in VTK. Tim Thirion is fixing up some iOS build issues and David Lonnie is working on removing an old text mapper that was causing some issues. JC has been working on updating Slicer to build against the current VTK with OpenGL2. Thanks Ken [1] http://review.source.kitware.com/#/t/5130/ [2] http://review.source.kitware.com/#/t/5171/ [3] http://review.source.kitware.com/#/t/5198/ [4] http://review.source.kitware.com/#/t/5248/ [5] http://review.source.kitware.com/#/t/5276/ [6] http://review.source.kitware.com/#/t/5302/ [7] http://review.source.kitware.com/#/t/5327/ Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) 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 dcthomas at utexas.edu Fri Sep 4 10:31:23 2015 From: dcthomas at utexas.edu (Derek C Thomas) Date: Fri, 4 Sep 2015 08:31:23 -0600 Subject: [vtk-developers] Spline effort and tests Message-ID: I came across the recent work on surface and volume Bezier and NURBS patches. David Thompson informed me that the tests are failing due to missing data. Is there somewhere I can find that data? I also have a question regarding the implementation. Would it be possible to use this work to generate a nonlinear cell type to represent an unstructured grid of Bezier patches? Thanks, Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Sep 4 10:55:10 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 4 Sep 2015 10:55:10 -0400 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: Message-ID: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> Hi Derek, Lin should be able to point you at the test data. It should be on Midas, so he may just send the URL (hint hint). > I also have a question regarding the implementation. Would it be possible to use this work to generate a nonlinear cell type to represent an unstructured grid of Bezier patches? Yes. The idea is that you would write an adaptor like the one Lin has written for NURBS to convert your non-linear data into B?zier patches. The patches can either be tessellated directly or operations performed on the patches. I am working on a contouring algorithm that would take patches in and output more B?zier patches of just the ioscontours/isovolumes, but it will be some time before it is ready. David From majcjc at gmail.com Fri Sep 4 21:35:45 2015 From: majcjc at gmail.com (Lin M) Date: Sat, 5 Sep 2015 09:35:45 +0800 Subject: [vtk-developers] Spline effort and tests In-Reply-To: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> Message-ID: Hi Derek, I put it in my public folder with the name Moto.brep ( http://midas3.kitware.com/midas/folder/13193). Please let me know if you have any other questions. :-) Best, Lin On Fri, Sep 4, 2015 at 10:55 PM, David Thompson wrote: > Hi Derek, > > Lin should be able to point you at the test data. It should be on Midas, > so he may just send the URL (hint hint). > > > I also have a question regarding the implementation. Would it be > possible to use this work to generate a nonlinear cell type to represent an > unstructured grid of Bezier patches? > > Yes. The idea is that you would write an adaptor like the one Lin has > written for NURBS to convert your non-linear data into B?zier patches. The > patches can either be tessellated directly or operations performed on the > patches. > > I am working on a contouring algorithm that would take patches in and > output more B?zier patches of just the ioscontours/isovolumes, but it will > be some time before it is ready. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Fri Sep 4 21:47:09 2015 From: majcjc at gmail.com (Lin M) Date: Sat, 5 Sep 2015 09:47:09 +0800 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> Message-ID: Hi Dr. Thompson, Some of the tests are still failing. 1. The header test output that Use export macro: VTKFILTERSBEZIER_EXPORT File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: 23: #include "vtkObject.h" 24: #include "vtkFiltersBezierModule.h" where I have no clue the problem is, and also File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: 28: #include "vtkAlgorithm.h" 29: #include "vtkFiltersBezierModule.h" File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor Should be: vtkBREPReader(const vtkBREPReader&); // Not implemented File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator Should be: void operator=(const vtkBREPReader&); // Not implemented where I really have implemented them. 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. The lines in the valid image have different line width the rendered test image in different platforms. Could you give me some suggestions about how to fix that? Thank you! Best, Lin On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: > Hi Derek, > > I put it in my public folder with the name Moto.brep ( > http://midas3.kitware.com/midas/folder/13193). > Please let me know if you have any other questions. :-) > > Best, > Lin > > > > > On Fri, Sep 4, 2015 at 10:55 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Derek, >> >> Lin should be able to point you at the test data. It should be on Midas, >> so he may just send the URL (hint hint). >> >> > I also have a question regarding the implementation. Would it be >> possible to use this work to generate a nonlinear cell type to represent an >> unstructured grid of Bezier patches? >> >> Yes. The idea is that you would write an adaptor like the one Lin has >> written for NURBS to convert your non-linear data into B?zier patches. The >> patches can either be tessellated directly or operations performed on the >> patches. >> >> I am working on a contouring algorithm that would take patches in and >> output more B?zier patches of just the ioscontours/isovolumes, but it will >> be some time before it is ready. >> >> David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Sep 5 08:08:14 2015 From: david.thompson at kitware.com (David Thompson) Date: Sat, 5 Sep 2015 08:08:14 -0400 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> Message-ID: <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Hi Lin, The header test is telling you to add an export macro defined in vtkFiltersBezierModule.h to each class in the module. It means that you should declare the classes like this: class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like #include "vtkFiltersBezierModule.h" // for export macro The only mandatory header file is the one for the declared class's parent. You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. David > On Sep 4, 2015, at 21:47, Lin M wrote: > > Hi Dr. Thompson, > > Some of the tests are still failing. > > 1. The header test output that > Use export macro: VTKFILTERSBEZIER_EXPORT > > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: > 23: #include "vtkObject.h" > 24: #include "vtkFiltersBezierModule.h" > where I have no clue the problem is, and also > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: > 28: #include "vtkAlgorithm.h" > 29: #include "vtkFiltersBezierModule.h" > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor > Should be: > vtkBREPReader(const vtkBREPReader&); // Not implemented > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator > Should be: > void operator=(const vtkBREPReader&); // Not implemented > where I really have implemented them. > > 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. > The lines in the valid image have different line width the rendered test image in different platforms. > Could you give me some suggestions about how to fix that? Thank you! > > Best, > Lin > >> On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: >> Hi Derek, >> >> I put it in my public folder with the name Moto.brep (http://midas3.kitware.com/midas/folder/13193). >> Please let me know if you have any other questions. :-) >> >> Best, >> Lin >> >> >> >> >>> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson wrote: >>> Hi Derek, >>> >>> Lin should be able to point you at the test data. It should be on Midas, so he may just send the URL (hint hint). >>> >>> > I also have a question regarding the implementation. Would it be possible to use this work to generate a nonlinear cell type to represent an unstructured grid of Bezier patches? >>> >>> Yes. The idea is that you would write an adaptor like the one Lin has written for NURBS to convert your non-linear data into B?zier patches. The patches can either be tessellated directly or operations performed on the patches. >>> >>> I am working on a contouring algorithm that would take patches in and output more B?zier patches of just the ioscontours/isovolumes, but it will be some time before it is ready. >>> >>> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Sat Sep 5 10:13:56 2015 From: majcjc at gmail.com (Lin M) Date: Sat, 5 Sep 2015 22:13:56 +0800 Subject: [vtk-developers] Spline effort and tests In-Reply-To: <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Message-ID: Hi Dr. Thompson, I checked the code. I think I have been following these rules but I still got the fail message in CDash ( https://open.cdash.org/testDetails.php?test=367888290&build=3981191) The declaration is like: ( https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBezierPatchAdaptor.h ) class VTKFILTERSBEZIER_EXPORT vtkBezierPatchAdaptor : public vtkObject {...} and only with two includes, one is "vtkObject.h" and another one is "vtkFiltersBezierModule.h" In vtkBREPReader.h ( https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBREPReader.h ) I declared the copy constructor and assignment operators as private methods without implementation. The main differences are 1. the vtkBezierPatchAdaptor is an abstract class so it doesn't have a static New() method. 2. the vtkBREPReader's parent class is vtkAlgorithm. Is it possible that I made some mistakes in the CMakeLists ( https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/CMakeLists.txt )? Best, Lin On Sat, Sep 5, 2015 at 8:08 PM, David Thompson wrote: > Hi Lin, > > The header test is telling you to add an export macro defined in > vtkFiltersBezierModule.h to each class in the module. It means that you > should declare the classes like this: > > class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; > > On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). > > The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like > > #include "vtkFiltersBezierModule.h" // for export macro > > The only mandatory header file is the one for the declared class's parent. > > You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. > > The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. > > David > > > On Sep 4, 2015, at 21:47, Lin M wrote: > > Hi Dr. Thompson, > > Some of the tests are still failing. > > 1. The header test output that > > Use export macro: VTKFILTERSBEZIER_EXPORT > > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: > 23: #include "vtkObject.h" > 24: #include "vtkFiltersBezierModule.h" > > where I have no clue the problem is, and also > > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: > 28: #include "vtkAlgorithm.h" > 29: #include "vtkFiltersBezierModule.h" > > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor > Should be: > vtkBREPReader(const vtkBREPReader&); // Not implemented > File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator > Should be: > void operator=(const vtkBREPReader&); // Not implemented > > where I really have implemented them. > > > 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. > > The lines in the valid image have different line width the rendered test image in different platforms. > > Could you give me some suggestions about how to fix that? Thank you! > > > Best, > > Lin > > > On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: > >> Hi Derek, >> >> I put it in my public folder with the name Moto.brep ( >> http://midas3.kitware.com/midas/folder/13193). >> Please let me know if you have any other questions. :-) >> >> Best, >> Lin >> >> >> >> >> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Derek, >>> >>> Lin should be able to point you at the test data. It should be on Midas, >>> so he may just send the URL (hint hint). >>> >>> > I also have a question regarding the implementation. Would it be >>> possible to use this work to generate a nonlinear cell type to represent an >>> unstructured grid of Bezier patches? >>> >>> Yes. The idea is that you would write an adaptor like the one Lin has >>> written for NURBS to convert your non-linear data into B?zier patches. The >>> patches can either be tessellated directly or operations performed on the >>> patches. >>> >>> I am working on a contouring algorithm that would take patches in and >>> output more B?zier patches of just the ioscontours/isovolumes, but it will >>> be some time before it is ready. >>> >>> David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Sep 5 10:48:41 2015 From: david.thompson at kitware.com (David Thompson) Date: Sat, 5 Sep 2015 10:48:41 -0400 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Message-ID: Hi Lin, You need to add a comment after one of the #include directives (explaining why the extra include is required) and after each of the private methods (saying exactly "Not implemented."). The header test looks for certain comments as a way to ensure that the developer is aware of the VTK style. David > On Sep 5, 2015, at 10:13, Lin M wrote: > > Hi Dr. Thompson, > > I checked the code. I think I have been following these rules but I still got the fail message in CDash (https://open.cdash.org/testDetails.php?test=367888290&build=3981191) > > The declaration is like: (https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBezierPatchAdaptor.h) > > class VTKFILTERSBEZIER_EXPORT vtkBezierPatchAdaptor : public vtkObject > {...} > > and only with two includes, one is "vtkObject.h" and another one is "vtkFiltersBezierModule.h" > > In vtkBREPReader.h (https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBREPReader.h) > > I declared the copy constructor and assignment operators as private methods without implementation. > > The main differences are 1. the vtkBezierPatchAdaptor is an abstract class so it doesn't have a static New() method. 2. the vtkBREPReader's parent class is vtkAlgorithm. > > Is it possible that I made some mistakes in the CMakeLists (https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/CMakeLists.txt)? > > Best, > Lin > >> On Sat, Sep 5, 2015 at 8:08 PM, David Thompson wrote: >> Hi Lin, >> >> The header test is telling you to add an export macro defined in vtkFiltersBezierModule.h to each class in the module. It means that you should declare the classes like this: >> class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; >> On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). >> The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like >> #include "vtkFiltersBezierModule.h" // for export macro >> The only mandatory header file is the one for the declared class's parent. >> You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. >> The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. >> David >> >>> On Sep 4, 2015, at 21:47, Lin M wrote: >>> >>> Hi Dr. Thompson, >>> >>> Some of the tests are still failing. >>> >>> 1. The header test output that >>> Use export macro: VTKFILTERSBEZIER_EXPORT >>> >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: >>> 23: #include "vtkObject.h" >>> 24: #include "vtkFiltersBezierModule.h" >>> where I have no clue the problem is, and also >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: >>> 28: #include "vtkAlgorithm.h" >>> 29: #include "vtkFiltersBezierModule.h" >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor >>> Should be: >>> vtkBREPReader(const vtkBREPReader&); // Not implemented >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator >>> Should be: >>> void operator=(const vtkBREPReader&); // Not implemented >>> where I really have implemented them. >>> >>> 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. >>> The lines in the valid image have different line width the rendered test image in different platforms. >>> Could you give me some suggestions about how to fix that? Thank you! >>> >>> Best, >>> Lin >>> >>>> On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: >>>> Hi Derek, >>>> >>>> I put it in my public folder with the name Moto.brep (http://midas3.kitware.com/midas/folder/13193). >>>> Please let me know if you have any other questions. :-) >>>> >>>> Best, >>>> Lin >>>> >>>> >>>> >>>> >>>>> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson wrote: >>>>> Hi Derek, >>>>> >>>>> Lin should be able to point you at the test data. It should be on Midas, so he may just send the URL (hint hint). >>>>> >>>>> > I also have a question regarding the implementation. Would it be possible to use this work to generate a nonlinear cell type to represent an unstructured grid of Bezier patches? >>>>> >>>>> Yes. The idea is that you would write an adaptor like the one Lin has written for NURBS to convert your non-linear data into B?zier patches. The patches can either be tessellated directly or operations performed on the patches. >>>>> >>>>> I am working on a contouring algorithm that would take patches in and output more B?zier patches of just the ioscontours/isovolumes, but it will be some time before it is ready. >>>>> >>>>> David >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sat Sep 5 13:11:58 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 5 Sep 2015 13:11:58 -0400 Subject: [vtk-developers] OSMesa regression Message-ID: Folks, git bisect identified this commit # first bad commit: [f09903e468b60c20a1e30cb665a5a72a8ab3140f] COMP: Add logic to selectively use OpenGL or OSMesa. https://gitlab.kitware.com/vtk/vtk/merge_requests/427 causes these errors in my OSMesa build: Linking CXX shared library ../../lib/libvtkGUISupportQt-6.3.so CMakeFiles/vtkGUISupportQt.dir/QVTKWidget.cxx.o: In function `QVTKWidget::x11_setup_window()': /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:736: undefined reference to `XGetWindowAttributes' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:740: undefined reference to `XCreateWindow' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:746: undefined reference to `XGetWMColormapWindows' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:750: undefined reference to `XFree' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:777: undefined reference to `XSetWMColormapWindows' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:780: undefined reference to `XFree' /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:782: undefined reference to `XFlush' collect2: error: ld returned 1 exit status make[3]: *** [lib/libvtkGUISupportQt-6.3.so.1] Error 1 make[2]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2 make[1]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/rule] Error 2 make: *** [vtkGUISupportQt] Error 2 From EVENDUAN at outlook.com Sat Sep 5 21:11:35 2015 From: EVENDUAN at outlook.com (=?gb2312?B?ts671Lrq?=) Date: Sun, 6 Sep 2015 09:11:35 +0800 Subject: [vtk-developers] Using marching cube to reconstruct pulmonary parenchyma Message-ID: I want use the following code to extract the lung parenchyma from CT Sequence Datasets. But when I set the skinExtractor?s value under 300,it will be an debug error and can?t get the lung parenchyma I want . So what?s wrong with my code. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MarchingCubes.cpp URL: From majcjc at gmail.com Sun Sep 6 02:12:41 2015 From: majcjc at gmail.com (Lin M) Date: Sun, 6 Sep 2015 14:12:41 +0800 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Message-ID: Hi Dr. Thompson, Thank you for your reminder! I also found that I need to exclude the template class vtkControlPointArray from the header test and it passed now. Currently from the CDash, there are still several problems to make it ready to merge. The first is still the test data for brepreader. Is there a way to upload it into the source/Testing/Data folder? The second is a building error in linux. ( https://open.cdash.org/viewBuildError.php?buildid=3996031 ) The third is a test failure in vtkFiltersCorePython-cutPolygons. ( https://open.cdash.org/testDetails.php?test=370902790&build=3996015 ) These two problems seem not relate to the vtkFiltersBezier module. Can I just ignore them? Best, Lin On Sat, Sep 5, 2015 at 10:48 PM, David Thompson wrote: > Hi Lin, > > You need to add a comment after one of the #include directives (explaining > why the extra include is required) and after each of the private methods > (saying exactly "Not implemented."). The header test looks for certain > comments as a way to ensure that the developer is aware of the VTK style. > > David > > On Sep 5, 2015, at 10:13, Lin M wrote: > > Hi Dr. Thompson, > > I checked the code. I think I have been following these rules but I still > got the fail message in CDash ( > https://open.cdash.org/testDetails.php?test=367888290&build=3981191) > > The declaration is like: ( > https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBezierPatchAdaptor.h > ) > > class VTKFILTERSBEZIER_EXPORT vtkBezierPatchAdaptor : public vtkObject > {...} > > and only with two includes, one is "vtkObject.h" and another one is > "vtkFiltersBezierModule.h" > > In vtkBREPReader.h ( > https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBREPReader.h > ) > > I declared the copy constructor and assignment operators as private > methods without implementation. > > The main differences are 1. the vtkBezierPatchAdaptor is an abstract class > so it doesn't have a static New() method. 2. the vtkBREPReader's parent > class is vtkAlgorithm. > > Is it possible that I made some mistakes in the CMakeLists ( > https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/CMakeLists.txt > )? > > Best, > Lin > > On Sat, Sep 5, 2015 at 8:08 PM, David Thompson > wrote: > >> Hi Lin, >> >> The header test is telling you to add an export macro defined in >> vtkFiltersBezierModule.h to each class in the module. It means that you >> should declare the classes like this: >> >> class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; >> >> On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). >> >> The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like >> >> #include "vtkFiltersBezierModule.h" // for export macro >> >> The only mandatory header file is the one for the declared class's parent. >> >> You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. >> >> The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. >> >> David >> >> >> On Sep 4, 2015, at 21:47, Lin M wrote: >> >> Hi Dr. Thompson, >> >> Some of the tests are still failing. >> >> 1. The header test output that >> >> Use export macro: VTKFILTERSBEZIER_EXPORT >> >> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: >> 23: #include "vtkObject.h" >> 24: #include "vtkFiltersBezierModule.h" >> >> where I have no clue the problem is, and also >> >> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: >> 28: #include "vtkAlgorithm.h" >> 29: #include "vtkFiltersBezierModule.h" >> >> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor >> Should be: >> vtkBREPReader(const vtkBREPReader&); // Not implemented >> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator >> Should be: >> void operator=(const vtkBREPReader&); // Not implemented >> >> where I really have implemented them. >> >> >> 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. >> >> The lines in the valid image have different line width the rendered test image in different platforms. >> >> Could you give me some suggestions about how to fix that? Thank you! >> >> >> Best, >> >> Lin >> >> >> On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: >> >>> Hi Derek, >>> >>> I put it in my public folder with the name Moto.brep ( >>> http://midas3.kitware.com/midas/folder/13193). >>> Please let me know if you have any other questions. :-) >>> >>> Best, >>> Lin >>> >>> >>> >>> >>> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> >>>> Hi Derek, >>>> >>>> Lin should be able to point you at the test data. It should be on >>>> Midas, so he may just send the URL (hint hint). >>>> >>>> > I also have a question regarding the implementation. Would it be >>>> possible to use this work to generate a nonlinear cell type to represent an >>>> unstructured grid of Bezier patches? >>>> >>>> Yes. The idea is that you would write an adaptor like the one Lin has >>>> written for NURBS to convert your non-linear data into B?zier patches. The >>>> patches can either be tessellated directly or operations performed on the >>>> patches. >>>> >>>> I am working on a contouring algorithm that would take patches in and >>>> output more B?zier patches of just the ioscontours/isovolumes, but it will >>>> be some time before it is ready. >>>> >>>> David >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Sep 7 14:43:57 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 7 Sep 2015 14:43:57 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: More information... This build uses off screen rendering with os mesa. The system has qt installed. Originally I had these settings. Worked OK until the git bisect commit. VTK_BUILD_ALL_MODULES:BOOL=ON VTK_USE_OFFSCREEN:BOOL=ON VTK_OPENGL_HAS_OSMESA:BOOL=ON VTK_USE_X:BOOL=ON Then I changed to the following: VTK_BUILD_ALL_MODULES:BOOL=OFF VTK_USE_OFFSCREEN:BOOL=ON VTK_OPENGL_HAS_OSMESA:BOOL=ON VTK_USE_X:BOOL=OFF VTK_Group_Imaging:BOOL=ON VTK_Group_Qt:BOOL=OFF VTK_Group_Rendering:BOOL=ON VTK_Group_StandAlone:BOOL=ON VTK_Group_Views:BOOL=ON So the referenced commit is still a regression, but I can workaround it. Bill On Sat, Sep 5, 2015 at 1:11 PM, Bill Lorensen wrote: > Folks, > > git bisect identified this commit > # first bad commit: [f09903e468b60c20a1e30cb665a5a72a8ab3140f] COMP: > Add logic to selectively use OpenGL or OSMesa. > https://gitlab.kitware.com/vtk/vtk/merge_requests/427 > > causes these errors in my OSMesa build: > Linking CXX shared library ../../lib/libvtkGUISupportQt-6.3.so > CMakeFiles/vtkGUISupportQt.dir/QVTKWidget.cxx.o: In function > `QVTKWidget::x11_setup_window()': > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:736: > undefined reference to `XGetWindowAttributes' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:740: > undefined reference to `XCreateWindow' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:746: > undefined reference to `XGetWMColormapWindows' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:750: > undefined reference to `XFree' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:777: > undefined reference to `XSetWMColormapWindows' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:780: > undefined reference to `XFree' > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:782: > undefined reference to `XFlush' > collect2: error: ld returned 1 exit status > make[3]: *** [lib/libvtkGUISupportQt-6.3.so.1] Error 1 > make[2]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2 > make[1]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/rule] Error 2 > make: *** [vtkGUISupportQt] Error 2 -- Unpaid intern in BillsBasement at noware dot com From dan.lipsa at kitware.com Mon Sep 7 16:01:34 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Mon, 7 Sep 2015 16:01:34 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: Hi Bill, I'll look into it. Dan On Mon, Sep 7, 2015 at 2:43 PM, Bill Lorensen wrote: > More information... > > This build uses off screen rendering with os mesa. The system has qt > installed. > > Originally I had these settings. Worked OK until the git bisect commit. > VTK_BUILD_ALL_MODULES:BOOL=ON > VTK_USE_OFFSCREEN:BOOL=ON > VTK_OPENGL_HAS_OSMESA:BOOL=ON > VTK_USE_X:BOOL=ON > > Then I changed to the following: > VTK_BUILD_ALL_MODULES:BOOL=OFF > VTK_USE_OFFSCREEN:BOOL=ON > VTK_OPENGL_HAS_OSMESA:BOOL=ON > VTK_USE_X:BOOL=OFF > VTK_Group_Imaging:BOOL=ON > VTK_Group_Qt:BOOL=OFF > VTK_Group_Rendering:BOOL=ON > VTK_Group_StandAlone:BOOL=ON > VTK_Group_Views:BOOL=ON > > So the referenced commit is still a regression, but I can workaround it. > > Bill > > > > > On Sat, Sep 5, 2015 at 1:11 PM, Bill Lorensen > wrote: > > Folks, > > > > git bisect identified this commit > > # first bad commit: [f09903e468b60c20a1e30cb665a5a72a8ab3140f] COMP: > > Add logic to selectively use OpenGL or OSMesa. > > https://gitlab.kitware.com/vtk/vtk/merge_requests/427 > > > > causes these errors in my OSMesa build: > > Linking CXX shared library ../../lib/libvtkGUISupportQt-6.3.so > > CMakeFiles/vtkGUISupportQt.dir/QVTKWidget.cxx.o: In function > > `QVTKWidget::x11_setup_window()': > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:736: > > undefined reference to `XGetWindowAttributes' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:740: > > undefined reference to `XCreateWindow' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:746: > > undefined reference to `XGetWMColormapWindows' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:750: > > undefined reference to `XFree' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:777: > > undefined reference to `XSetWMColormapWindows' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:780: > > undefined reference to `XFree' > > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:782: > > undefined reference to `XFlush' > > collect2: error: ld returned 1 exit status > > make[3]: *** [lib/libvtkGUISupportQt-6.3.so.1] Error 1 > > make[2]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2 > > make[1]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/rule] Error 2 > > make: *** [vtkGUISupportQt] Error 2 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 8 11:31:07 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 8 Sep 2015 09:31:07 -0600 Subject: [vtk-developers] Removing interface methods with no implementation Message-ID: Hi All, I have a commit in the pipeline that removes unimplemented methods from vtkTextureObject, vtkAMRBox, and vtkX3DExportFIWriter. Please take a look and let me know if you forgot to implement one of the following: ;-) unsigned int vtkTextureObject::GetDepthTextureModeFormat(int vtktype); vtkAMRBox::vtkAMRBox(int ilo,int jlo, int ihi, int jhi); // 2D box constructor int vtkX3DExporterFIWriter::GetEncodingMethod(); The commit itself: https://gitlab.kitware.com/dgobbi/vtk/commit/d24ca13c - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcthomas at utexas.edu Tue Sep 8 13:11:52 2015 From: dcthomas at utexas.edu (Derek C Thomas) Date: Tue, 8 Sep 2015 11:11:52 -0600 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Message-ID: Lin, Thank you for the data. Where should this data be placed to run the tests? Derek On Sun, Sep 6, 2015 at 12:12 AM, Lin M wrote: > Hi Dr. Thompson, > > Thank you for your reminder! I also found that I need to exclude the > template class vtkControlPointArray from the header test and it passed now. > > Currently from the CDash, there are still several problems to make it > ready to merge. > > The first is still the test data for brepreader. Is there a way to upload > it into the source/Testing/Data folder? > > The second is a building error in linux. ( > https://open.cdash.org/viewBuildError.php?buildid=3996031 ) > The third is a test failure in vtkFiltersCorePython-cutPolygons. ( > https://open.cdash.org/testDetails.php?test=370902790&build=3996015 ) > These two problems seem not relate to the vtkFiltersBezier module. Can I > just ignore them? > > Best, > Lin > > On Sat, Sep 5, 2015 at 10:48 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> You need to add a comment after one of the #include directives >> (explaining why the extra include is required) and after each of the >> private methods (saying exactly "Not implemented."). The header test looks >> for certain comments as a way to ensure that the developer is aware of the >> VTK style. >> >> David >> >> On Sep 5, 2015, at 10:13, Lin M wrote: >> >> Hi Dr. Thompson, >> >> I checked the code. I think I have been following these rules but I still >> got the fail message in CDash ( >> https://open.cdash.org/testDetails.php?test=367888290&build=3981191) >> >> The declaration is like: ( >> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBezierPatchAdaptor.h >> ) >> >> class VTKFILTERSBEZIER_EXPORT vtkBezierPatchAdaptor : public vtkObject >> {...} >> >> and only with two includes, one is "vtkObject.h" and another one is >> "vtkFiltersBezierModule.h" >> >> In vtkBREPReader.h ( >> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBREPReader.h >> ) >> >> I declared the copy constructor and assignment operators as private >> methods without implementation. >> >> The main differences are 1. the vtkBezierPatchAdaptor is an abstract >> class so it doesn't have a static New() method. 2. the vtkBREPReader's >> parent class is vtkAlgorithm. >> >> Is it possible that I made some mistakes in the CMakeLists ( >> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/CMakeLists.txt >> )? >> >> Best, >> Lin >> >> On Sat, Sep 5, 2015 at 8:08 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> The header test is telling you to add an export macro defined in >>> vtkFiltersBezierModule.h to each class in the module. It means that you >>> should declare the classes like this: >>> >>> class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; >>> >>> On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). >>> >>> The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like >>> >>> #include "vtkFiltersBezierModule.h" // for export macro >>> >>> The only mandatory header file is the one for the declared class's parent. >>> >>> You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. >>> >>> The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. >>> >>> David >>> >>> >>> On Sep 4, 2015, at 21:47, Lin M wrote: >>> >>> Hi Dr. Thompson, >>> >>> Some of the tests are still failing. >>> >>> 1. The header test output that >>> >>> Use export macro: VTKFILTERSBEZIER_EXPORT >>> >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: >>> 23: #include "vtkObject.h" >>> 24: #include "vtkFiltersBezierModule.h" >>> >>> where I have no clue the problem is, and also >>> >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: >>> 28: #include "vtkAlgorithm.h" >>> 29: #include "vtkFiltersBezierModule.h" >>> >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor >>> Should be: >>> vtkBREPReader(const vtkBREPReader&); // Not implemented >>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator >>> Should be: >>> void operator=(const vtkBREPReader&); // Not implemented >>> >>> where I really have implemented them. >>> >>> >>> 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. >>> >>> The lines in the valid image have different line width the rendered test image in different platforms. >>> >>> Could you give me some suggestions about how to fix that? Thank you! >>> >>> >>> Best, >>> >>> Lin >>> >>> >>> On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: >>> >>>> Hi Derek, >>>> >>>> I put it in my public folder with the name Moto.brep ( >>>> http://midas3.kitware.com/midas/folder/13193). >>>> Please let me know if you have any other questions. :-) >>>> >>>> Best, >>>> Lin >>>> >>>> >>>> >>>> >>>> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson < >>>> david.thompson at kitware.com> wrote: >>>> >>>>> Hi Derek, >>>>> >>>>> Lin should be able to point you at the test data. It should be on >>>>> Midas, so he may just send the URL (hint hint). >>>>> >>>>> > I also have a question regarding the implementation. Would it be >>>>> possible to use this work to generate a nonlinear cell type to represent an >>>>> unstructured grid of Bezier patches? >>>>> >>>>> Yes. The idea is that you would write an adaptor like the one Lin has >>>>> written for NURBS to convert your non-linear data into B?zier patches. The >>>>> patches can either be tessellated directly or operations performed on the >>>>> patches. >>>>> >>>>> I am working on a contouring algorithm that would take patches in and >>>>> output more B?zier patches of just the ioscontours/isovolumes, but it will >>>>> be some time before it is ready. >>>>> >>>>> David >>>> >>>> >>>> >>> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Tue Sep 8 13:27:51 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 8 Sep 2015 13:27:51 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: Hi Bill, I am not sure why you got the link error with your initial combination of parameters. VTK_USE_X=ON overrides VTK_OPENGL_HAS_OSMESA=ON so the QT modules should have linked fine. They do link on my machine. Do you have a CMakeCache.txt? In that case, there is no offscreen rendering though. I did get the link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=OFF as QVTKWidget needs X. I have a merge request that excludes Qt modules if VTK_OPENGL_HAS_OSMESA=ON I also got a link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=ON because some cxx files in Rendering/OpenGL used code ifdef with VTK_OPENGL_HAS_OSMESA instead of VTK_USE_OSMESA. The merge request that fixes these problems is: https://gitlab.kitware.com/vtk/vtk/merge_requests/637 All these were parameter combinations not test by our dashboards. When we wanted OSMESA we did VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=OFF and we disabled the Qt modules. Dan On Mon, Sep 7, 2015 at 4:01 PM, Dan Lipsa wrote: > Hi Bill, > I'll look into it. > > Dan > > > On Mon, Sep 7, 2015 at 2:43 PM, Bill Lorensen > wrote: > >> More information... >> >> This build uses off screen rendering with os mesa. The system has qt >> installed. >> >> Originally I had these settings. Worked OK until the git bisect commit. >> VTK_BUILD_ALL_MODULES:BOOL=ON >> VTK_USE_OFFSCREEN:BOOL=ON >> VTK_OPENGL_HAS_OSMESA:BOOL=ON >> VTK_USE_X:BOOL=ON >> >> Then I changed to the following: >> VTK_BUILD_ALL_MODULES:BOOL=OFF >> VTK_USE_OFFSCREEN:BOOL=ON >> VTK_OPENGL_HAS_OSMESA:BOOL=ON >> VTK_USE_X:BOOL=OFF >> VTK_Group_Imaging:BOOL=ON >> VTK_Group_Qt:BOOL=OFF >> VTK_Group_Rendering:BOOL=ON >> VTK_Group_StandAlone:BOOL=ON >> VTK_Group_Views:BOOL=ON >> >> So the referenced commit is still a regression, but I can workaround it. >> >> Bill >> >> >> >> >> On Sat, Sep 5, 2015 at 1:11 PM, Bill Lorensen >> wrote: >> > Folks, >> > >> > git bisect identified this commit >> > # first bad commit: [f09903e468b60c20a1e30cb665a5a72a8ab3140f] COMP: >> > Add logic to selectively use OpenGL or OSMesa. >> > https://gitlab.kitware.com/vtk/vtk/merge_requests/427 >> > >> > causes these errors in my OSMesa build: >> > Linking CXX shared library ../../lib/libvtkGUISupportQt-6.3.so >> > CMakeFiles/vtkGUISupportQt.dir/QVTKWidget.cxx.o: In function >> > `QVTKWidget::x11_setup_window()': >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:736: >> > undefined reference to `XGetWindowAttributes' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:740: >> > undefined reference to `XCreateWindow' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:746: >> > undefined reference to `XGetWMColormapWindows' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:750: >> > undefined reference to `XFree' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:777: >> > undefined reference to `XSetWMColormapWindows' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:780: >> > undefined reference to `XFree' >> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:782: >> > undefined reference to `XFlush' >> > collect2: error: ld returned 1 exit status >> > make[3]: *** [lib/libvtkGUISupportQt-6.3.so.1] Error 1 >> > make[2]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2 >> > make[1]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/rule] Error 2 >> > make: *** [vtkGUISupportQt] Error 2 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Tue Sep 8 13:36:17 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 8 Sep 2015 13:36:17 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: On Tue, Sep 8, 2015 at 1:27 PM, Dan Lipsa wrote: > Hi Bill, > I am not sure why you got the link error with your initial combination of > parameters. > VTK_USE_X=ON overrides VTK_OPENGL_HAS_OSMESA=ON so the QT modules should > have linked fine. They do link on my machine. Do you have a CMakeCache.txt? > In that case, there is no offscreen rendering though. > Actually, I misstated - I did not see the Qt modules linking. I seen the second link error I mentioned, the one in Rendering/OpenGL. After I fixed that the Qt modules linked fine. So do you mind trying the branch in my merge request to see if that fixes the problems you seen. Thanks, Dan > > I did get the link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=OFF as > QVTKWidget needs X. I have a merge request that excludes Qt modules > if VTK_OPENGL_HAS_OSMESA=ON > > I also got a link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=ON > because some cxx files in Rendering/OpenGL used code ifdef > with VTK_OPENGL_HAS_OSMESA instead of VTK_USE_OSMESA. > > The merge request that fixes these problems is: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/637 > > All these were parameter combinations not test by our dashboards. When we > wanted OSMESA we did VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=OFF and we > disabled the Qt modules. > > Dan > > > On Mon, Sep 7, 2015 at 4:01 PM, Dan Lipsa wrote: > >> Hi Bill, >> I'll look into it. >> >> Dan >> >> >> On Mon, Sep 7, 2015 at 2:43 PM, Bill Lorensen >> wrote: >> >>> More information... >>> >>> This build uses off screen rendering with os mesa. The system has qt >>> installed. >>> >>> Originally I had these settings. Worked OK until the git bisect commit. >>> VTK_BUILD_ALL_MODULES:BOOL=ON >>> VTK_USE_OFFSCREEN:BOOL=ON >>> VTK_OPENGL_HAS_OSMESA:BOOL=ON >>> VTK_USE_X:BOOL=ON >>> >>> Then I changed to the following: >>> VTK_BUILD_ALL_MODULES:BOOL=OFF >>> VTK_USE_OFFSCREEN:BOOL=ON >>> VTK_OPENGL_HAS_OSMESA:BOOL=ON >>> VTK_USE_X:BOOL=OFF >>> VTK_Group_Imaging:BOOL=ON >>> VTK_Group_Qt:BOOL=OFF >>> VTK_Group_Rendering:BOOL=ON >>> VTK_Group_StandAlone:BOOL=ON >>> VTK_Group_Views:BOOL=ON >>> >>> So the referenced commit is still a regression, but I can workaround it. >>> >>> Bill >>> >>> >>> >>> >>> On Sat, Sep 5, 2015 at 1:11 PM, Bill Lorensen >>> wrote: >>> > Folks, >>> > >>> > git bisect identified this commit >>> > # first bad commit: [f09903e468b60c20a1e30cb665a5a72a8ab3140f] COMP: >>> > Add logic to selectively use OpenGL or OSMesa. >>> > https://gitlab.kitware.com/vtk/vtk/merge_requests/427 >>> > >>> > causes these errors in my OSMesa build: >>> > Linking CXX shared library ../../lib/libvtkGUISupportQt-6.3.so >>> > CMakeFiles/vtkGUISupportQt.dir/QVTKWidget.cxx.o: In function >>> > `QVTKWidget::x11_setup_window()': >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:736: >>> > undefined reference to `XGetWindowAttributes' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:740: >>> > undefined reference to `XCreateWindow' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:746: >>> > undefined reference to `XGetWMColormapWindows' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:750: >>> > undefined reference to `XFree' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:777: >>> > undefined reference to `XSetWMColormapWindows' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:780: >>> > undefined reference to `XFree' >>> > /home/lorensen/ProjectsGIT/VTKGerrit/GUISupport/Qt/QVTKWidget.cxx:782: >>> > undefined reference to `XFlush' >>> > collect2: error: ld returned 1 exit status >>> > make[3]: *** [lib/libvtkGUISupportQt-6.3.so.1] Error 1 >>> > make[2]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2 >>> > make[1]: *** [GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/rule] Error >>> 2 >>> > make: *** [vtkGUISupportQt] Error 2 >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Tue Sep 8 14:49:00 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 8 Sep 2015 14:49:00 -0400 Subject: [vtk-developers] OSMesa regression In-Reply-To: References: Message-ID: > > Hi Bill, > I broke my initial merge request for the two errors I have seen into a merge request and a bug report. > >> I did get the link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=OFF >> as QVTKWidget needs X. I have a merge request that excludes Qt modules >> if VTK_OPENGL_HAS_OSMESA=ON >> > I demoted this to just a bug report as the fix was not ideal. http://www.vtk.org/Bug/view.php?id=15713 > >> I also got a link error for VTK_OPENGL_HAS_OSMESA=ON and VTK_USE_X=ON >> because some cxx files in Rendering/OpenGL used code ifdef >> with VTK_OPENGL_HAS_OSMESA instead of VTK_USE_OSMESA. >> > This is a merge request that should fix the regression you have seen: https://gitlab.kitware.com/vtk/vtk/merge_requests/637 Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Sep 8 16:03:04 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 8 Sep 2015 16:03:04 -0400 Subject: [vtk-developers] ANNOUNCE: Kitware is hiring Message-ID: Hi folks, We are looking to hire visualization developers to our Scientific Computing team. If you are a talented visualization researcher and developer with strong C++ skills, please consider applying. You will join a great team and work on many interesting and challenging technical problems - always aiming to deliver robust and widely used software solutions. For the full posting see: http://tinyurl.com/l8sgvzw JOB DESCRIPTION Kitware is seeking to hire highly skilled Research and Development Engineers (R&D Engineers) to join our Scientific Computing team and contribute to our scientific and information visualization efforts. Candidates will work to develop and improve leading visualization software solutions. Kitware collaborates on a multitude of basic and applied research and development projects. Our collaborators include the top universities from around the world, national research labs, medical device manufacturers, car manufacturers, oil and gas companies, financial institutes, and many others. The projects range from extending our open source C++ libraries and applications, such as VTK, ParaView, and CMake, to developing proprietary domain-specific vertical applications for a wide array of platforms including web and mobile devices. By joining our team you will participate in a dynamic work environment with exceptionally talented and friendly coworkers who are committed to high-quality development practices. You will collaborate with esteemed researchers from around the world by: * Designing and developing scalable data analysis and visualization tools for use by researchers and professionals from various domains; * Solving a wide array of problems ranging from developing distributed memory parallel algorithms for data analysis, optimizing distributed parallel codes to compiling and maintaining software on supercomputers. * Designing and developing tools to improve scientific data analysis workflows; * Contributing to and supporting our dynamic open source communities built around several of our open source tools. -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Tue Sep 8 20:47:21 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 9 Sep 2015 08:47:21 +0800 Subject: [vtk-developers] Spline effort and tests In-Reply-To: References: <2FF7D5D0-58D1-4620-9480-033A3795BA96@kitware.com> <17288704-5427-4C25-B379-331AA23F3BCD@kitware.com> Message-ID: Hi Derek, You can put it in the source/Testing/Data/ folder. That should do the work. :-) Best, Lin On Wed, Sep 9, 2015 at 1:11 AM, Derek C Thomas wrote: > Lin, > > Thank you for the data. Where should this data be placed to run the tests? > > Derek > > On Sun, Sep 6, 2015 at 12:12 AM, Lin M wrote: > >> Hi Dr. Thompson, >> >> Thank you for your reminder! I also found that I need to exclude the >> template class vtkControlPointArray from the header test and it passed now. >> >> Currently from the CDash, there are still several problems to make it >> ready to merge. >> >> The first is still the test data for brepreader. Is there a way to upload >> it into the source/Testing/Data folder? >> >> The second is a building error in linux. ( >> https://open.cdash.org/viewBuildError.php?buildid=3996031 ) >> The third is a test failure in vtkFiltersCorePython-cutPolygons. ( >> https://open.cdash.org/testDetails.php?test=370902790&build=3996015 ) >> These two problems seem not relate to the vtkFiltersBezier module. Can I >> just ignore them? >> >> Best, >> Lin >> >> On Sat, Sep 5, 2015 at 10:48 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> You need to add a comment after one of the #include directives >>> (explaining why the extra include is required) and after each of the >>> private methods (saying exactly "Not implemented."). The header test looks >>> for certain comments as a way to ensure that the developer is aware of the >>> VTK style. >>> >>> David >>> >>> On Sep 5, 2015, at 10:13, Lin M wrote: >>> >>> Hi Dr. Thompson, >>> >>> I checked the code. I think I have been following these rules but I >>> still got the fail message in CDash ( >>> https://open.cdash.org/testDetails.php?test=367888290&build=3981191) >>> >>> The declaration is like: ( >>> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBezierPatchAdaptor.h >>> ) >>> >>> class VTKFILTERSBEZIER_EXPORT vtkBezierPatchAdaptor : public vtkObject >>> {...} >>> >>> and only with two includes, one is "vtkObject.h" and another one is >>> "vtkFiltersBezierModule.h" >>> >>> In vtkBREPReader.h ( >>> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/vtkBREPReader.h >>> ) >>> >>> I declared the copy constructor and assignment operators as private >>> methods without implementation. >>> >>> The main differences are 1. the vtkBezierPatchAdaptor is an abstract >>> class so it doesn't have a static New() method. 2. the vtkBREPReader's >>> parent class is vtkAlgorithm. >>> >>> Is it possible that I made some mistakes in the CMakeLists ( >>> https://gitlab.kitware.com/Lin.Ma/vtk/blob/master/Filters/Bezier/CMakeLists.txt >>> )? >>> >>> Best, >>> Lin >>> >>> On Sat, Sep 5, 2015 at 8:08 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> >>>> Hi Lin, >>>> >>>> The header test is telling you to add an export macro defined in >>>> vtkFiltersBezierModule.h to each class in the module. It means that you >>>> should declare the classes like this: >>>> >>>> class VTKFILTERSBEZIER_EXPORT vtkXXX { ... }; >>>> >>>> On Windows, the macro is turned into a declspec that tells the compiler the class is part of the library's public API (instead of for internal use only). >>>> >>>> The test also complains that your header file includes more than one other header. We have had problems with compilation times for VTK growing very large because developers would add many include statements to the headers (instead of putting them in the implementation file, where they belong). To keep that from happening again, the header test complains when there is more than one include file. When the include file is necessary, simply add a comment explaining why it is needed to the right of the include statement, like >>>> >>>> #include "vtkFiltersBezierModule.h" // for export macro >>>> >>>> The only mandatory header file is the one for the declared class's parent. >>>> >>>> You should not implement the copy constructor and assignment operators. Instead, you should declare them as private methods and provide no implementation. Classes derived from vtkObject (which should be the default) should have instances created by calling a static New() method, should always be referenced by pointer instead of by value, and should not be copied unless ShallowCopy or DeepCopy methods are implemented. This is a design pattern used throughout VTK to make memory management safer. >>>> >>>> The failing image tests can be fixed by adding images that are correct but drawn with a few different pixels. Each test can have multiple valid baseline images. Just download the image from the dashboard web page, name it baseline_1.png (assuming the original was baseline.png), and add its MD5 checksum to the Data directory. There should be mention of how to do this on the wiki. >>>> >>>> David >>>> >>>> >>>> On Sep 4, 2015, at 21:47, Lin M wrote: >>>> >>>> Hi Dr. Thompson, >>>> >>>> Some of the tests are still failing. >>>> >>>> 1. The header test output that >>>> >>>> Use export macro: VTKFILTERSBEZIER_EXPORT >>>> >>>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBezierPatchAdaptor.h has 2 includes: >>>> 23: #include "vtkObject.h" >>>> 24: #include "vtkFiltersBezierModule.h" >>>> >>>> where I have no clue the problem is, and also >>>> >>>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h has 2 includes: >>>> 28: #include "vtkAlgorithm.h" >>>> 29: #include "vtkFiltersBezierModule.h" >>>> >>>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define copy constructor >>>> Should be: >>>> vtkBREPReader(const vtkBREPReader&); // Not implemented >>>> File: c:/Dashboards/buildbot/eec47309/source/Filters/Bezier/vtkBREPReader.h does not define assignment operator >>>> Should be: >>>> void operator=(const vtkBREPReader&); // Not implemented >>>> >>>> where I really have implemented them. >>>> >>>> >>>> 2. The image tests seems to fail because of there are some slightly differences between the test image and the valid image. >>>> >>>> The lines in the valid image have different line width the rendered test image in different platforms. >>>> >>>> Could you give me some suggestions about how to fix that? Thank you! >>>> >>>> >>>> Best, >>>> >>>> Lin >>>> >>>> >>>> On Sat, Sep 5, 2015 at 9:35 AM, Lin M wrote: >>>> >>>>> Hi Derek, >>>>> >>>>> I put it in my public folder with the name Moto.brep ( >>>>> http://midas3.kitware.com/midas/folder/13193). >>>>> Please let me know if you have any other questions. :-) >>>>> >>>>> Best, >>>>> Lin >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 4, 2015 at 10:55 PM, David Thompson < >>>>> david.thompson at kitware.com> wrote: >>>>> >>>>>> Hi Derek, >>>>>> >>>>>> Lin should be able to point you at the test data. It should be on >>>>>> Midas, so he may just send the URL (hint hint). >>>>>> >>>>>> > I also have a question regarding the implementation. Would it be >>>>>> possible to use this work to generate a nonlinear cell type to represent an >>>>>> unstructured grid of Bezier patches? >>>>>> >>>>>> Yes. The idea is that you would write an adaptor like the one Lin has >>>>>> written for NURBS to convert your non-linear data into B?zier patches. The >>>>>> patches can either be tessellated directly or operations performed on the >>>>>> patches. >>>>>> >>>>>> I am working on a contouring algorithm that would take patches in and >>>>>> output more B?zier patches of just the ioscontours/isovolumes, but it will >>>>>> be some time before it is ready. >>>>>> >>>>>> David >>>>> >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Sep 9 09:08:53 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 9 Sep 2015 09:08:53 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style Message-ID: Hi folks, What would you think of changing VTK's indentation style from: if () { // .. } to if () { // ... } ? Our current style (modified Whitesmiths I am told) is used only by very few projects, mostly related to VTK ones (ITK, CMake). It is poorly supported by some of the newer editors that are widely popular (Sublime, TextMate etc.) and IMO foreign to the new generation C++ developers. The style I propose is modified Allman style - with indentation changed from 4 to 2 spaces. It is much more common. If approved by the community, we would change VTK wholesale. This should not be an issue for history as git blame/annotate can be told to skip white spaces. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Sep 9 09:14:06 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 9 Sep 2015 09:14:06 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: +1 David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci wrote: > Hi folks, > > What would you think of changing VTK's indentation style from: > > if () > { > // .. > } > > to > > if () > { > // ... > } > > ? > > Our current style (modified Whitesmiths I am told) is used only by very > few projects, > mostly related to VTK ones (ITK, CMake). It is poorly supported by some of > the newer editors > that are widely popular (Sublime, TextMate etc.) and IMO foreign to the > new generation > C++ developers. > > The style I propose is modified Allman style - with indentation changed > from 4 to 2 spaces. > It is much more common. > > If approved by the community, we would change VTK wholesale. This should > not be > an issue for history as git blame/annotate can be told to skip white > spaces. > > Best, > -berk > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 9 09:20:52 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Sep 2015 07:20:52 -0600 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: +1 On Wed, Sep 9, 2015 at 7:14 AM, David E DeMarle wrote: > +1 > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci > wrote: > >> Hi folks, >> >> What would you think of changing VTK's indentation style from: >> >> if () >> { >> // .. >> } >> >> to >> >> if () >> { >> // ... >> } >> >> ? >> >> Our current style (modified Whitesmiths I am told) is used only by very >> few projects, >> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >> of the newer editors >> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >> new generation >> C++ developers. >> >> The style I propose is modified Allman style - with indentation changed >> from 4 to 2 spaces. >> It is much more common. >> >> If approved by the community, we would change VTK wholesale. This should >> not be >> an issue for history as git blame/annotate can be told to skip white >> spaces. >> >> Best, >> -berk >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 9 09:21:29 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 09:21:29 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <55F03259.2000404@kitware.com> On 09/09/2015 09:08 AM, Berk Geveci wrote: > What would you think of changing VTK's indentation style [snip] > If approved by the community, we would change VTK wholesale. Yes, the transition could be done by a sweeping commit by kwrobot. We could also try to define the style more formally by using clang-format: http://clang.llvm.org/docs/ClangFormat.html The tool can lay out code automatically, has editor integration, can be configured with a file in the source tree, and has a few widely used styles as starting points. -Brad From david.lonie at kitware.com Wed Sep 9 09:22:37 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 9 Sep 2015 09:22:37 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: Well, if we're changing it anyway... I'd prefer void func() { if (...) { ... } else { ... } } Less wasted vertical space = more code on the screen, and it's a common style with great editor support. I've always been a fan of the Qt coding style. https://wiki.qt.io/Qt_Coding_Style That said, either would be fine with me. Dave On Wed, Sep 9, 2015 at 9:14 AM, David E DeMarle wrote: > +1 > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci > wrote: > >> Hi folks, >> >> What would you think of changing VTK's indentation style from: >> >> if () >> { >> // .. >> } >> >> to >> >> if () >> { >> // ... >> } >> >> ? >> >> Our current style (modified Whitesmiths I am told) is used only by very >> few projects, >> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >> of the newer editors >> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >> new generation >> C++ developers. >> >> The style I propose is modified Allman style - with indentation changed >> from 4 to 2 spaces. >> It is much more common. >> >> If approved by the community, we would change VTK wholesale. This should >> not be >> an issue for history as git blame/annotate can be told to skip white >> spaces. >> >> Best, >> -berk >> >> _______________________________________________ >> 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 ben.boeckel at kitware.com Wed Sep 9 09:43:27 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Sep 2015 09:43:27 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <20150909134327.GA2859@megas.kitware.com> On Wed, Sep 09, 2015 at 09:22:37 -0400, David Lonie wrote: > Well, if we're changing it anyway... > > I'd prefer > > void func() > { > if (...) { > ... > } > else { > ... > } > } > > Less wasted vertical space = more code on the screen, and it's a common > style with great editor support. I've always been a fan of the Qt coding > style. > > https://wiki.qt.io/Qt_Coding_Style > > That said, either would be fine with me. I'm not too wedded to either (I personally prefer Allman for C++, but K&R braces for C, Rust, JavaScript, and other "braced" languages[1], though I've preferred using "} else {" to the style here[2]). No matter what, can we please (continue to) enforce that braces are *always* used even if the innards are a single line? --Ben [1]Rust, JS, and Java have style guidelines. C is usually because the projects in C I work on are contributions and copying upstream is best. [2]"Robin's egg blue is obviously better than turquoise" :P From shawn.waldon at kitware.com Wed Sep 9 09:53:26 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 9 Sep 2015 09:53:26 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150909134327.GA2859@megas.kitware.com> References: <20150909134327.GA2859@megas.kitware.com> Message-ID: +1 It would be nice to have a format that doesn't require twiddling with the editor(s) so much. Having said that, I prefer that we do what Brad suggested and use clang-format. I've used it before on a project in grad school and it was nice not having to worry about whitespace while coding since I could just run a command to fix it at the end. Shawn On Wed, Sep 9, 2015 at 9:43 AM, Ben Boeckel wrote: > On Wed, Sep 09, 2015 at 09:22:37 -0400, David Lonie wrote: > > Well, if we're changing it anyway... > > > > I'd prefer > > > > void func() > > { > > if (...) { > > ... > > } > > else { > > ... > > } > > } > > > > Less wasted vertical space = more code on the screen, and it's a common > > style with great editor support. I've always been a fan of the Qt coding > > style. > > > > https://wiki.qt.io/Qt_Coding_Style > > > > That said, either would be fine with me. > > I'm not too wedded to either (I personally prefer Allman for C++, but > K&R braces for C, Rust, JavaScript, and other "braced" languages[1], though > I've preferred using "} else {" to the style here[2]). > > No matter what, can we please (continue to) enforce that braces are > *always* used even if the innards are a single line? > > --Ben > > [1]Rust, JS, and Java have style guidelines. C is usually because the > projects in C I work on are contributions and copying upstream is best. > [2]"Robin's egg blue is obviously better than turquoise" :P > _______________________________________________ > 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 Sep 9 09:57:20 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 9 Sep 2015 09:57:20 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <20150909135720.723775632@mail.rogue-research.com> On Wed, 9 Sep 2015 09:08:53 -0400, Berk Geveci said: >What would you think of changing VTK's indentation style from: > >if () > { > // .. > } > >to > >if () >{ > // ... >} +100 :) I rather hate the current style. :) I've used clang-format and uncrustify too, and vote that whatever we choose we should be sure it works with these types of tools. Personally, I prefer the braces on their own lines, but putting the opening brace at the end of the line is fine too. Agree with Ben that we should always use braces, even for one-line 'ifs'. 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 aashish.chaudhary at kitware.com Wed Sep 9 10:03:50 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 9 Sep 2015 10:03:50 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: +1 On Wed, Sep 9, 2015 at 9:20 AM, David Gobbi wrote: > +1 > > > On Wed, Sep 9, 2015 at 7:14 AM, David E DeMarle > wrote: > >> +1 >> >> >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci >> wrote: >> >>> Hi folks, >>> >>> What would you think of changing VTK's indentation style from: >>> >>> if () >>> { >>> // .. >>> } >>> >>> to >>> >>> if () >>> { >>> // ... >>> } >>> >>> ? >>> >>> Our current style (modified Whitesmiths I am told) is used only by very >>> few projects, >>> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >>> of the newer editors >>> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >>> new generation >>> C++ developers. >>> >>> The style I propose is modified Allman style - with indentation changed >>> from 4 to 2 spaces. >>> It is much more common. >>> >>> If approved by the community, we would change VTK wholesale. This should >>> not be >>> an issue for history as git blame/annotate can be told to skip white >>> spaces. >>> >>> Best, >>> -berk >>> >> > _______________________________________________ > 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 > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Wed Sep 9 10:08:25 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 9 Sep 2015 10:08:25 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150909135720.723775632@mail.rogue-research.com> References: <20150909135720.723775632@mail.rogue-research.com> Message-ID: +1 Everyone I know has commented on the oddity of the current brace style. I'm used to it now, but it won't take much to adjust to the proposed style. I think I prefer braces on separate lines to keep conditional keywords aligned vertically. On Wed, Sep 9, 2015 at 9:57 AM, Sean McBride wrote: > On Wed, 9 Sep 2015 09:08:53 -0400, Berk Geveci said: > > >What would you think of changing VTK's indentation style from: > > > >if () > > { > > // .. > > } > > > >to > > > >if () > >{ > > // ... > >} > > +100 :) I rather hate the current style. :) > > I've used clang-format and uncrustify too, and vote that whatever we > choose we should be sure it works with these types of tools. > > Personally, I prefer the braces on their own lines, but putting the > opening brace at the end of the line is fine too. > > Agree with Ben that we should always use braces, even for one-line 'ifs'. > > 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 > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaffra at gmail.com Wed Sep 9 10:18:43 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Wed, 9 Sep 2015 10:18:43 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <55F03FC3.8040307@gmail.com> +1 On 9/9/2015 10:03 AM, Aashish Chaudhary wrote: > +1 > > On Wed, Sep 9, 2015 at 9:20 AM, David Gobbi > wrote: > > +1 > > > On Wed, Sep 9, 2015 at 7:14 AM, David E DeMarle > > wrote: > > +1 > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci > > wrote: > > Hi folks, > > What would you think of changing VTK's indentation style from: > > if () > { > // .. > } > > to > > if () > { > // ... > } > > ? > > Our current style (modified Whitesmiths I am told) is used > only by very few projects, > mostly related to VTK ones (ITK, CMake). It is poorly > supported by some of the newer editors > that are widely popular (Sublime, TextMate etc.) and IMO > foreign to the new generation > C++ developers. > > The style I propose is modified Allman style - with > indentation changed from 4 to 2 spaces. > It is much more common. > > If approved by the community, we would change VTK > wholesale. This should not be > an issue for history as git blame/annotate can be told to > skip white spaces. > > Best, > -berk > > > _______________________________________________ > 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 > > > > > > -- > /| Aashish Chaudhary > | Technical Leader > | Kitware Inc. > / > /| http://www.kitware.com/company/team/chaudhary.html/ > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 9 10:12:21 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Sep 2015 08:12:21 -0600 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <55F03259.2000404@kitware.com> References: <55F03259.2000404@kitware.com> Message-ID: On Wed, Sep 9, 2015 at 7:21 AM, Brad King wrote: > > Yes, the transition could be done by a sweeping commit by kwrobot. > > We could also try to define the style more formally by using > clang-format: > > http://clang.llvm.org/docs/ClangFormat.html The only styling change that the robot should do is removal of the two preceding spaces before the braces. Otherwise, we will have to contend with the law of unintended consequences. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Sep 9 10:46:04 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Sep 2015 10:46:04 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <55F03259.2000404@kitware.com> Message-ID: <20150909144604.GA31739@megas.kitware.com> On Wed, Sep 09, 2015 at 08:12:21 -0600, David Gobbi wrote: > The only styling change that the robot should do is removal of the two > preceding spaces before the braces. Otherwise, we will have to contend > with the law of unintended consequences. Agreed. It will also (hopefully) keep "blame poisoning" down to just brace-only lines. --Ben From brad.king at kitware.com Wed Sep 9 10:56:41 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 10:56:41 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150909144604.GA31739@megas.kitware.com> References: <55F03259.2000404@kitware.com> <20150909144604.GA31739@megas.kitware.com> Message-ID: <55F048A9.9010204@kitware.com> On 09/09/2015 10:46 AM, Ben Boeckel wrote: > On Wed, Sep 09, 2015 at 08:12:21 -0600, David Gobbi wrote: >> The only styling change that the robot should do is removal of the two >> preceding spaces before the braces. Otherwise, we will have to contend >> with the law of unintended consequences. > > Agreed. It will also (hopefully) keep "blame poisoning" down to just > brace-only lines. No. If we are going to change style any more than just {} indentation then blame poisoning is inevitable. The only way to avoid it would be to make style changes incrementally as code is edited, but that would be very confusing. Given that such style updates must be done as a sweeping commit, would we rather blame kwrobot or a person? In CMake's own source we made a few sweeping kwrobot commits to update whitespace and convert *.cmake commands to lower case. Those few commits still regularly show up in blame output but it is not very bothersome to blame starting from $blamed~1 instead. -Brad From wascott at sandia.gov Wed Sep 9 12:51:09 2015 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 9 Sep 2015 16:51:09 +0000 Subject: [vtk-developers] [EXTERNAL] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <2627d2862dd84849892904adaf0e4ca4@ES01AMSNLNT.srn.sandia.gov> I have never liked the current indent style, and have always used and liked the one you propose. Alan From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Wednesday, September 09, 2015 7:09 AM To: VTK Developers Subject: [EXTERNAL] [vtk-developers] PROPOSAL: Changing VTK's indentation style Hi folks, What would you think of changing VTK's indentation style from: if () { // .. } to if () { // ... } ? Our current style (modified Whitesmiths I am told) is used only by very few projects, mostly related to VTK ones (ITK, CMake). It is poorly supported by some of the newer editors that are widely popular (Sublime, TextMate etc.) and IMO foreign to the new generation C++ developers. The style I propose is modified Allman style - with indentation changed from 4 to 2 spaces. It is much more common. If approved by the community, we would change VTK wholesale. This should not be an issue for history as git blame/annotate can be told to skip white spaces. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Wed Sep 9 14:17:16 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 9 Sep 2015 14:17:16 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: +1 I found the VTK formatting very foreign when I first start using VTK - now I got used with it. For everything else I used the format you propose. Dan On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci wrote: > Hi folks, > > What would you think of changing VTK's indentation style from: > > if () > { > // .. > } > > to > > if () > { > // ... > } > > ? > > Our current style (modified Whitesmiths I am told) is used only by very > few projects, > mostly related to VTK ones (ITK, CMake). It is poorly supported by some of > the newer editors > that are widely popular (Sublime, TextMate etc.) and IMO foreign to the > new generation > C++ developers. > > The style I propose is modified Allman style - with indentation changed > from 4 to 2 spaces. > It is much more common. > > If approved by the community, we would change VTK wholesale. This should > not be > an issue for history as git blame/annotate can be told to skip white > spaces. > > Best, > -berk > > _______________________________________________ > 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 tim.thirion at kitware.com Wed Sep 9 14:21:32 2015 From: tim.thirion at kitware.com (Tim Thirion) Date: Wed, 9 Sep 2015 14:21:32 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: +1 I still find the current brace style hard to read after a year of development. TT On Wed, Sep 9, 2015 at 2:17 PM, Dan Lipsa wrote: > +1 > I found the VTK formatting very foreign when I first start using VTK - now > I got used with it. > > For everything else I used the format you propose. > Dan > > > On Wed, Sep 9, 2015 at 9:08 AM, Berk Geveci > wrote: > >> Hi folks, >> >> What would you think of changing VTK's indentation style from: >> >> if () >> { >> // .. >> } >> >> to >> >> if () >> { >> // ... >> } >> >> ? >> >> Our current style (modified Whitesmiths I am told) is used only by very >> few projects, >> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >> of the newer editors >> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >> new generation >> C++ developers. >> >> The style I propose is modified Allman style - with indentation changed >> from 4 to 2 spaces. >> It is much more common. >> >> If approved by the community, we would change VTK wholesale. This should >> not be >> an issue for history as git blame/annotate can be told to skip white >> spaces. >> >> Best, >> -berk >> >> _______________________________________________ >> 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 brad.king at kitware.com Wed Sep 9 15:41:43 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 15:41:43 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> Message-ID: <55F08B77.1070804@kitware.com> On 9/9/2015 9:53 AM, Shawn Waldon wrote: > It would be nice to have a format that doesn't require twiddling > with the editor(s) so much. Yes. > Having said that, I prefer that we do what > Brad suggested and use clang-format. After further thought I think we should delay consideration of clang-format. Let's not allow it to get in the way of Berk's original proposal. It has a lot of +1s. On 9/9/2015 9:22 AM, David Lonie wrote: > if (...) { > ... > } > else { > ... > } [snip] On 9/9/2015 9:43 AM, Ben Boeckel wrote: > I've preferred using "} else {" I also like if (...) { ... } else { ... } and it seems to be widely used. The placement of the opening curly on the block opening line or on its own line does not affect the indentation of the code inside the curly braces, so this choice can be made locally rather than mandated globally. -------------------------------------------------------------------- I propose that we start with a sweeping change implementing Berk's original proposal of just moving the curly braces up one level of indentation: if (...) { ... } else { ... } Then in future edits and/or new code we can allow the opening "{" to be either on its own line or on the block opening line as preferred by individuals. Changes to curly brace placement can be made incrementally as code is edited to avoid blame poisoning. -Brad From brad.king at kitware.com Wed Sep 9 15:41:46 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 15:41:46 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> Message-ID: <55F08B7A.2030007@kitware.com> On 9/9/2015 9:53 AM, Shawn Waldon wrote: > It would be nice to have a format that doesn't require twiddling > with the editor(s) so much. Yes. > Having said that, I prefer that we do what > Brad suggested and use clang-format. After further thought I think we should delay consideration of clang-format. Let's not allow it to get in the way of Berk's original proposal. It has a lot of +1s. On 9/9/2015 9:22 AM, David Lonie wrote: > if (...) { > ... > } > else { > ... > } [snip] On 9/9/2015 9:43 AM, Ben Boeckel wrote: > I've preferred using "} else {" I also like if (...) { ... } else { ... } and it seems to be widely used. The placement of the opening curly on the block opening line or on its own line does not affect the indentation of the code inside the curly braces, so this choice can be made locally rather than mandated globally. -------------------------------------------------------------------- I propose that we start with a sweeping change implementing Berk's original proposal of just moving the curly braces up one level of indentation: if (...) { ... } else { ... } Then in future edits and/or new code we can allow the opening "{" to be either on its own line or on the block opening line as preferred by individuals. Changes to curly brace placement can be made incrementally as code is edited to avoid blame poisoning. -Brad From berk.geveci at kitware.com Wed Sep 9 15:57:17 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 9 Sep 2015 15:57:17 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <55F08B77.1070804@kitware.com> References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> Message-ID: +1 to Brad's suggestion, On Wed, Sep 9, 2015 at 3:41 PM, Brad King wrote: > On 9/9/2015 9:53 AM, Shawn Waldon wrote: > > It would be nice to have a format that doesn't require twiddling > > with the editor(s) so much. > > Yes. > > > Having said that, I prefer that we do what > > Brad suggested and use clang-format. > > After further thought I think we should delay consideration of > clang-format. Let's not allow it to get in the way of Berk's > original proposal. It has a lot of +1s. > > On 9/9/2015 9:22 AM, David Lonie wrote: > > if (...) { > > ... > > } > > else { > > ... > > } > [snip] > On 9/9/2015 9:43 AM, Ben Boeckel wrote: > > I've preferred using "} else {" > > I also like > > if (...) { > ... > } else { > ... > } > > and it seems to be widely used. The placement of the opening > curly on the block opening line or on its own line does not > affect the indentation of the code inside the curly braces, > so this choice can be made locally rather than mandated > globally. > > -------------------------------------------------------------------- > > I propose that we start with a sweeping change implementing > Berk's original proposal of just moving the curly braces up > one level of indentation: > > if (...) > { > ... > } > else > { > ... > } > > Then in future edits and/or new code we can allow the opening > "{" to be either on its own line or on the block opening line as > preferred by individuals. Changes to curly brace placement can > be made incrementally as code is edited to avoid blame poisoning. > > -Brad > _______________________________________________ > 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 Sep 9 16:26:02 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 9 Sep 2015 16:26:02 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> Message-ID: <63bb5cb7797a87f517c27a07999eda27@mail.gmail.com> If () { Blah } +2 If () { Blah } +1 Allowing people to use whichever one they feel like -10 I find that code consistency makes it a lot easier for me to get into a new class in VTK. So I would say if you want to move to ?if () {? then do it all at once and then that is the standard. I think most everyone agrees that Berk?s original suggestion is an improvement. I?m not as sure about switching to ?if () { ? I think that could be more divisive. Maybe not. FWIW my brain still hurts when I see four different ways of creating an instance spread throughout the code ala VTK_NEW(class) vtkNew vtkSmartPointer class::New() I have no clue which one to use so I try to use them all equally, in the same function :-) Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Berk Geveci *Sent:* Wednesday, September 9, 2015 3:57 PM *To:* Brad King *Cc:* VTK Developers *Subject:* Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style +1 to Brad's suggestion, On Wed, Sep 9, 2015 at 3:41 PM, Brad King wrote: On 9/9/2015 9:53 AM, Shawn Waldon wrote: > It would be nice to have a format that doesn't require twiddling > with the editor(s) so much. Yes. > Having said that, I prefer that we do what > Brad suggested and use clang-format. After further thought I think we should delay consideration of clang-format. Let's not allow it to get in the way of Berk's original proposal. It has a lot of +1s. On 9/9/2015 9:22 AM, David Lonie wrote: > if (...) { > ... > } > else { > ... > } [snip] On 9/9/2015 9:43 AM, Ben Boeckel wrote: > I've preferred using "} else {" I also like if (...) { ... } else { ... } and it seems to be widely used. The placement of the opening curly on the block opening line or on its own line does not affect the indentation of the code inside the curly braces, so this choice can be made locally rather than mandated globally. -------------------------------------------------------------------- I propose that we start with a sweeping change implementing Berk's original proposal of just moving the curly braces up one level of indentation: if (...) { ... } else { ... } Then in future edits and/or new code we can allow the opening "{" to be either on its own line or on the block opening line as preferred by individuals. Changes to curly brace placement can be made incrementally as code is edited to avoid blame poisoning. -Brad _______________________________________________ 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 wascott at sandia.gov Wed Sep 9 16:32:45 2015 From: wascott at sandia.gov (Scott, W Alan) Date: Wed, 9 Sep 2015 20:32:45 +0000 Subject: [vtk-developers] [EXTERNAL] Re: PROPOSAL: Changing VTK's indentation style In-Reply-To: <63bb5cb7797a87f517c27a07999eda27@mail.gmail.com> References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <63bb5cb7797a87f517c27a07999eda27@mail.gmail.com> Message-ID: <3bbbdb48860a42b7a0d9d8cec8260444@ES01AMSNLNT.srn.sandia.gov> +10 to this comment. From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Ken Martin Sent: Wednesday, September 09, 2015 2:26 PM To: Geveci, Berk (External Contact); Brad King Cc: VTK Developers Subject: [EXTERNAL] Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style If () { Blah } +2 If () { Blah } +1 Allowing people to use whichever one they feel like -10 I find that code consistency makes it a lot easier for me to get into a new class in VTK. So I would say if you want to move to ?if () {? then do it all at once and then that is the standard. I think most everyone agrees that Berk?s original suggestion is an improvement. I?m not as sure about switching to ?if () { ? I think that could be more divisive. Maybe not. FWIW my brain still hurts when I see four different ways of creating an instance spread throughout the code ala VTK_NEW(class) vtkNew vtkSmartPointer class::New() I have no clue which one to use so I try to use them all equally, in the same function :-) Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Wednesday, September 9, 2015 3:57 PM To: Brad King Cc: VTK Developers Subject: Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style +1 to Brad's suggestion, On Wed, Sep 9, 2015 at 3:41 PM, Brad King > wrote: On 9/9/2015 9:53 AM, Shawn Waldon wrote: > It would be nice to have a format that doesn't require twiddling > with the editor(s) so much. Yes. > Having said that, I prefer that we do what > Brad suggested and use clang-format. After further thought I think we should delay consideration of clang-format. Let's not allow it to get in the way of Berk's original proposal. It has a lot of +1s. On 9/9/2015 9:22 AM, David Lonie wrote: > if (...) { > ... > } > else { > ... > } [snip] On 9/9/2015 9:43 AM, Ben Boeckel wrote: > I've preferred using "} else {" I also like if (...) { ... } else { ... } and it seems to be widely used. The placement of the opening curly on the block opening line or on its own line does not affect the indentation of the code inside the curly braces, so this choice can be made locally rather than mandated globally. -------------------------------------------------------------------- I propose that we start with a sweeping change implementing Berk's original proposal of just moving the curly braces up one level of indentation: if (...) { ... } else { ... } Then in future edits and/or new code we can allow the opening "{" to be either on its own line or on the block opening line as preferred by individuals. Changes to curly brace placement can be made incrementally as code is edited to avoid blame poisoning. -Brad _______________________________________________ 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 Wed Sep 9 17:01:30 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Wed, 9 Sep 2015 17:01:30 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <55F08B77.1070804@kitware.com> References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> Message-ID: -1 for allowing different kinds of brace placement. On Wed, Sep 9, 2015 at 3:41 PM, Brad King wrote: > On 9/9/2015 9:53 AM, Shawn Waldon wrote: > > It would be nice to have a format that doesn't require twiddling > > with the editor(s) so much. > > Yes. > > > Having said that, I prefer that we do what > > Brad suggested and use clang-format. > > After further thought I think we should delay consideration of > clang-format. Let's not allow it to get in the way of Berk's > original proposal. It has a lot of +1s. > > On 9/9/2015 9:22 AM, David Lonie wrote: > > if (...) { > > ... > > } > > else { > > ... > > } > [snip] > On 9/9/2015 9:43 AM, Ben Boeckel wrote: > > I've preferred using "} else {" > > I also like > > if (...) { > ... > } else { > ... > } > > and it seems to be widely used. The placement of the opening > curly on the block opening line or on its own line does not > affect the indentation of the code inside the curly braces, > so this choice can be made locally rather than mandated > globally. > > -------------------------------------------------------------------- > > I propose that we start with a sweeping change implementing > Berk's original proposal of just moving the curly braces up > one level of indentation: > > if (...) > { > ... > } > else > { > ... > } > > Then in future edits and/or new code we can allow the opening > "{" to be either on its own line or on the block opening line as > preferred by individuals. Changes to curly brace placement can > be made incrementally as code is edited to avoid blame poisoning. > > -Brad > _______________________________________________ > 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 brad.king at kitware.com Wed Sep 9 17:29:16 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 17:29:16 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <55F08B77.1070804@kitware.com> References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> Message-ID: <55F0A4AC.8080107@kitware.com> On 9/9/2015 3:41 PM, Brad King wrote: > if (...) { > ... > } else { > ... > } [snip] > if (...) > { > ... > } > else > { > ... > } There seems to be agreement that either of these is an improvement but that we should choose now which one to use. I'm sure one can find endless debates across the web about which one is best. Here are the main reasons I prefer the former over the latter: 1. Uses less vertical space. This is important when the content within the blocks is short. 2. The start and end of each logical block is aligned horizontally and can be matched vertically with nothing in the way: if (...) { ^ ... | ... | ... | ... | ... v ... } else { ^ ... | ... | ... | ... | ... v ... } This is important when the content within the blocks is long. 3. Distinguishes conditional and unconditional blocks: if (...) { // conditional block } { // unconditional block } Contrast this to the latter style where both look the same: if (...) { // conditional block } { // unconditional block } In the latter style one must read a line above the "{" to see whether it is a condition. This could be tricky if there is an unrelated f(...) call there. The former style is widely used in many projects and well-supported by editors. -Brad From david.gobbi at gmail.com Wed Sep 9 18:05:44 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 9 Sep 2015 16:05:44 -0600 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <55F0A4AC.8080107@kitware.com> References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: Hi Brad, Even though I slightly prefer the inline "if () {" style, I can offer some arguments against it. 1) it doesn't work well for multi-line conditionals: for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } versus for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } 2) it's inherently inconsistent. This is demonstrated by the following Java-styled code that actually applies the style consistently: int myfunc(int x) { if (x == 0) { statements; } } Most C++ programmers (like myself) think the above is ridiculous, but really, why should a definition block be treated differently from a conditional block? In my opinion, putting the brace on the following line is nice because it is a simple, consistent rule that produces easily readable code. I'm a fan of compact code, but only when it is compactified according to my own tastes. Otherwise the compactification loses its value ;-) - David On Wed, Sep 9, 2015 at 3:29 PM, Brad King wrote: > On 9/9/2015 3:41 PM, Brad King wrote: > > if (...) { > > ... > > } else { > > ... > > } > [snip] > > if (...) > > { > > ... > > } > > else > > { > > ... > > } > > There seems to be agreement that either of these is an improvement > but that we should choose now which one to use. I'm sure one can > find endless debates across the web about which one is best. Here > are the main reasons I prefer the former over the latter: > > 1. Uses less vertical space. This is important when the content > within the blocks is short. > > 2. The start and end of each logical block is aligned horizontally > and can be matched vertically with nothing in the way: > > if (...) { > ^ ... > | ... > | ... > | ... > | ... > v ... > } else { > ^ ... > | ... > | ... > | ... > | ... > v ... > } > > This is important when the content within the blocks is long. > > 3. Distinguishes conditional and unconditional blocks: > > if (...) { > // conditional block > } > > { > // unconditional block > } > > Contrast this to the latter style where both look the same: > > if (...) > { > // conditional block > } > > { > // unconditional block > } > > In the latter style one must read a line above the "{" to see > whether it is a condition. This could be tricky if there is > an unrelated f(...) call there. > > The former style is widely used in many projects and well-supported > by editors. > > -Brad > _______________________________________________ > 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 kmorel at sandia.gov Wed Sep 9 18:26:38 2015 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Wed, 9 Sep 2015 22:26:38 +0000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style Message-ID: The braces on the same line or on its own is a six-or-half-dozen argument. There are reasons for both, and none of the reasons are compelling. I suggest leaving the braces on their own line simply to minimize the changes that will impact all of the VTK code. It looks like most if not all of us agree there is a big win shifting all the braces over two spaces to the left. There is a strong benefit to the move and a small impact to the history of the code (even considering blame). I am not seeing convincing reason and support to moving the braces to new lines, which is a very different visual look and has a much larger impact on the history. -Ken From: vtk-developers > on behalf of David Gobbi > Date: Wednesday, September 9, 2015 at 4:05 PM To: Brad King > Cc: VTK Developers > Subject: [EXTERNAL] Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style Hi Brad, Even though I slightly prefer the inline "if () {" style, I can offer some arguments against it. 1) it doesn't work well for multi-line conditionals: for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } versus for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } 2) it's inherently inconsistent. This is demonstrated by the following Java-styled code that actually applies the style consistently: int myfunc(int x) { if (x == 0) { statements; } } Most C++ programmers (like myself) think the above is ridiculous, but really, why should a definition block be treated differently from a conditional block? In my opinion, putting the brace on the following line is nice because it is a simple, consistent rule that produces easily readable code. I'm a fan of compact code, but only when it is compactified according to my own tastes. Otherwise the compactification loses its value ;-) - David On Wed, Sep 9, 2015 at 3:29 PM, Brad King > wrote: On 9/9/2015 3:41 PM, Brad King wrote: > if (...) { > ... > } else { > ... > } [snip] > if (...) > { > ... > } > else > { > ... > } There seems to be agreement that either of these is an improvement but that we should choose now which one to use. I'm sure one can find endless debates across the web about which one is best. Here are the main reasons I prefer the former over the latter: 1. Uses less vertical space. This is important when the content within the blocks is short. 2. The start and end of each logical block is aligned horizontally and can be matched vertically with nothing in the way: if (...) { ^ ... | ... | ... | ... | ... v ... } else { ^ ... | ... | ... | ... | ... v ... } This is important when the content within the blocks is long. 3. Distinguishes conditional and unconditional blocks: if (...) { // conditional block } { // unconditional block } Contrast this to the latter style where both look the same: if (...) { // conditional block } { // unconditional block } In the latter style one must read a line above the "{" to see whether it is a condition. This could be tricky if there is an unrelated f(...) call there. The former style is widely used in many projects and well-supported by editors. -Brad _______________________________________________ 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 pieper at isomics.com Wed Sep 9 18:27:26 2015 From: pieper at isomics.com (Steve Pieper) Date: Wed, 9 Sep 2015 18:27:26 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: I'd personally vote for: int func( int arg ) { // this code looks gorgeous! if ( condition ) { statement; } else { statement; } } But I'm also used to VTK's "unorthodox" style and don't really mind it. To be honest it makes it very clear when I'm looking at VTK code and when code has been written by novices vs old hands (and yes, sometimes I form opinions about likely code quality from that). I'd also like to point out that in Slicer our explicit style [1] is to copy VTK style for any code that inherits from VTK objects. So if VTK changes Slicer will have to also, and by implication all Slicer extensions should also change. This will create extra maintenance work and probably some confusion for our community (and I suspect other projects will have similar issues). Is the motivation for this change really worth introducing some busywork and confusion for people who use VTK? If yes, then +1. -Steve [1] http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi wrote: > Hi Brad, > > Even though I slightly prefer the inline "if () {" style, I can offer some > arguments against it. > > 1) it doesn't work well for multi-line conditionals: > > for (std::vector::iterator iter = vec.begin(); > iter != vec.end(); > ++iter) { > statements; > } > > versus > > for (std::vector::iterator iter = vec.begin(); > iter != vec.end(); > ++iter) > { > statements; > } > > 2) it's inherently inconsistent. This is demonstrated by the following > Java-styled code that actually applies the style consistently: > > int myfunc(int x) { > if (x == 0) { > statements; > } > } > > Most C++ programmers (like myself) think the above is ridiculous, but > really, why should a definition block be treated differently from a > conditional block? > > In my opinion, putting the brace on the following line is nice because it > is a simple, consistent rule that produces easily readable code. > > I'm a fan of compact code, but only when it is compactified according to > my own tastes. Otherwise the compactification loses its value ;-) > > - David > > > On Wed, Sep 9, 2015 at 3:29 PM, Brad King wrote: > >> On 9/9/2015 3:41 PM, Brad King wrote: >> > if (...) { >> > ... >> > } else { >> > ... >> > } >> [snip] >> > if (...) >> > { >> > ... >> > } >> > else >> > { >> > ... >> > } >> >> There seems to be agreement that either of these is an improvement >> but that we should choose now which one to use. I'm sure one can >> find endless debates across the web about which one is best. Here >> are the main reasons I prefer the former over the latter: >> >> 1. Uses less vertical space. This is important when the content >> within the blocks is short. >> >> 2. The start and end of each logical block is aligned horizontally >> and can be matched vertically with nothing in the way: >> >> if (...) { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } else { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } >> >> This is important when the content within the blocks is long. >> >> 3. Distinguishes conditional and unconditional blocks: >> >> if (...) { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> Contrast this to the latter style where both look the same: >> >> if (...) >> { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> In the latter style one must read a line above the "{" to see >> whether it is a condition. This could be tricky if there is >> an unrelated f(...) call there. >> >> The former style is widely used in many projects and well-supported >> by editors. >> >> -Brad >> _______________________________________________ >> 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 pieper at isomics.com Wed Sep 9 19:13:33 2015 From: pieper at isomics.com (Steve Pieper) Date: Wed, 9 Sep 2015 19:13:33 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: Has anyone raised the idea of changing the ITK or ParView styles? I suspect as separate projects they would have their own discussions. -Steve On Wed, Sep 9, 2015 at 6:41 PM, Andras Lasso wrote: > I would not worry too much about Slicer extensions. For example in our > extensions we already use the usual indentation instead of VTK?s. > > > > Note that ITK, Paraview, etc. would need to be updated to the same style, > too. > > > > Andras > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Steve Pieper > *Sent:* September 9, 2015 6:27 PM > *To:* David Gobbi > *Cc:* VTK Developers ; Brad King < > brad.king at kitware.com> > *Subject:* Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style > > > > I'd personally vote for: > > > > int func( int arg ) > > { > > // this code looks gorgeous! > > if ( condition ) { > > statement; > > } else { > > statement; > > } > > } > > > > But I'm also used to VTK's "unorthodox" style and don't really mind it. > To be honest it makes it very clear when I'm looking at VTK code and when > code has been written by novices vs old hands (and yes, sometimes I form > opinions about likely code quality from that). > > > > I'd also like to point out that in Slicer our explicit style [1] is to > copy VTK style for any code that inherits from VTK objects. So if VTK > changes Slicer will have to also, and by implication all Slicer extensions > should also change. This will create extra maintenance work and probably > some confusion for our community (and I suspect other projects will have > similar issues). > > > > Is the motivation for this change really worth introducing some busywork > and confusion for people who use VTK? If yes, then +1. > > > > -Steve > > > > [1] > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide > > > > > > > > On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi wrote: > > Hi Brad, > > > > Even though I slightly prefer the inline "if () {" style, I can offer some > arguments against it. > > > > 1) it doesn't work well for multi-line conditionals: > > > > for (std::vector::iterator iter = vec.begin(); > > iter != vec.end(); > > ++iter) { > > statements; > > } > > > > versus > > > > for (std::vector::iterator iter = vec.begin(); > > iter != vec.end(); > > ++iter) > > { > > statements; > > } > > > > 2) it's inherently inconsistent. This is demonstrated by the following > Java-styled code that actually applies the style consistently: > > > > int myfunc(int x) { > > if (x == 0) { > > statements; > > } > > } > > > > Most C++ programmers (like myself) think the above is ridiculous, but > really, why should a definition block be treated differently from a > conditional block? > > > > In my opinion, putting the brace on the following line is nice because it > is a simple, consistent rule that produces easily readable code. > > > > I'm a fan of compact code, but only when it is compactified according to > my own tastes. Otherwise the compactification loses its value ;-) > > > > - David > > > > > > On Wed, Sep 9, 2015 at 3:29 PM, Brad King wrote: > > On 9/9/2015 3:41 PM, Brad King wrote: > > if (...) { > > ... > > } else { > > ... > > } > [snip] > > if (...) > > { > > ... > > } > > else > > { > > ... > > } > > There seems to be agreement that either of these is an improvement > but that we should choose now which one to use. I'm sure one can > find endless debates across the web about which one is best. Here > are the main reasons I prefer the former over the latter: > > 1. Uses less vertical space. This is important when the content > within the blocks is short. > > 2. The start and end of each logical block is aligned horizontally > and can be matched vertically with nothing in the way: > > if (...) { > ^ ... > | ... > | ... > | ... > | ... > v ... > } else { > ^ ... > | ... > | ... > | ... > | ... > v ... > } > > This is important when the content within the blocks is long. > > 3. Distinguishes conditional and unconditional blocks: > > if (...) { > // conditional block > } > > { > // unconditional block > } > > Contrast this to the latter style where both look the same: > > if (...) > { > // conditional block > } > > { > // unconditional block > } > > In the latter style one must read a line above the "{" to see > whether it is a condition. This could be tricky if there is > an unrelated f(...) call there. > > The former style is widely used in many projects and well-supported > by editors. > > > -Brad > _______________________________________________ > 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 lasso at queensu.ca Wed Sep 9 18:41:31 2015 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 9 Sep 2015 22:41:31 +0000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: I would not worry too much about Slicer extensions. For example in our extensions we already use the usual indentation instead of VTK?s. Note that ITK, Paraview, etc. would need to be updated to the same style, too. Andras From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Steve Pieper Sent: September 9, 2015 6:27 PM To: David Gobbi Cc: VTK Developers ; Brad King Subject: Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style I'd personally vote for: int func( int arg ) { // this code looks gorgeous! if ( condition ) { statement; } else { statement; } } But I'm also used to VTK's "unorthodox" style and don't really mind it. To be honest it makes it very clear when I'm looking at VTK code and when code has been written by novices vs old hands (and yes, sometimes I form opinions about likely code quality from that). I'd also like to point out that in Slicer our explicit style [1] is to copy VTK style for any code that inherits from VTK objects. So if VTK changes Slicer will have to also, and by implication all Slicer extensions should also change. This will create extra maintenance work and probably some confusion for our community (and I suspect other projects will have similar issues). Is the motivation for this change really worth introducing some busywork and confusion for people who use VTK? If yes, then +1. -Steve [1] http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi > wrote: Hi Brad, Even though I slightly prefer the inline "if () {" style, I can offer some arguments against it. 1) it doesn't work well for multi-line conditionals: for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } versus for (std::vector::iterator iter = vec.begin(); iter != vec.end(); ++iter) { statements; } 2) it's inherently inconsistent. This is demonstrated by the following Java-styled code that actually applies the style consistently: int myfunc(int x) { if (x == 0) { statements; } } Most C++ programmers (like myself) think the above is ridiculous, but really, why should a definition block be treated differently from a conditional block? In my opinion, putting the brace on the following line is nice because it is a simple, consistent rule that produces easily readable code. I'm a fan of compact code, but only when it is compactified according to my own tastes. Otherwise the compactification loses its value ;-) - David On Wed, Sep 9, 2015 at 3:29 PM, Brad King > wrote: On 9/9/2015 3:41 PM, Brad King wrote: > if (...) { > ... > } else { > ... > } [snip] > if (...) > { > ... > } > else > { > ... > } There seems to be agreement that either of these is an improvement but that we should choose now which one to use. I'm sure one can find endless debates across the web about which one is best. Here are the main reasons I prefer the former over the latter: 1. Uses less vertical space. This is important when the content within the blocks is short. 2. The start and end of each logical block is aligned horizontally and can be matched vertically with nothing in the way: if (...) { ^ ... | ... | ... | ... | ... v ... } else { ^ ... | ... | ... | ... | ... v ... } This is important when the content within the blocks is long. 3. Distinguishes conditional and unconditional blocks: if (...) { // conditional block } { // unconditional block } Contrast this to the latter style where both look the same: if (...) { // conditional block } { // unconditional block } In the latter style one must read a line above the "{" to see whether it is a condition. This could be tricky if there is an unrelated f(...) call there. The former style is widely used in many projects and well-supported by editors. -Brad _______________________________________________ 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 biddisco at cscs.ch Thu Sep 10 02:49:08 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Thu, 10 Sep 2015 06:49:08 +0000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> +lots Like the Scottish who say ?Anyone but England?, I would like to emphatically vote in favour of changing VTK?s code style to ?Anything, but what we have now?, it certainly can?t get worse. Yours JB PS. It feels like 2006! I made my views felt then (and many times previously), and Berk has criticised my views on it for the last 10 years, so I shan?t say any more! http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: 09 September 2015 15:09 To: VTK Developers Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style Hi folks, What would you think of changing VTK's indentation style from: if () { // .. } to if () { // ... } ? Our current style (modified Whitesmiths I am told) is used only by very few projects, mostly related to VTK ones (ITK, CMake). It is poorly supported by some of the newer editors that are widely popular (Sublime, TextMate etc.) and IMO foreign to the new generation C++ developers. The style I propose is modified Allman style - with indentation changed from 4 to 2 spaces. It is much more common. If approved by the community, we would change VTK wholesale. This should not be an issue for history as git blame/annotate can be told to skip white spaces. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Sep 10 09:24:56 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 10 Sep 2015 09:24:56 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: I am still against your proposal John. For reference, it was this: > I would like to reserve the right to use my own coding style on the contributed class(es) It was not changing VTK's style to something different. Looking at that thread, it also looked like everyone that contributed to it except you were against it. Also looking at this thread, it sounds like many people are still against mixing multiple styles in the same codebase. Best, -berk On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. wrote: > +lots > > > > Like the Scottish who say ?Anyone but England?, I would like to > emphatically vote in favour of changing VTK?s code style to ?Anything, but > what we have now?, it certainly can?t get worse. > > > > Yours > > > > JB > > PS. It feels like 2006! I made my views felt then (and many times > previously), and Berk has criticised my views on it for the last 10 years, > so I shan?t say any more! > > > http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html > > > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Berk Geveci > *Sent:* 09 September 2015 15:09 > *To:* VTK Developers > *Subject:* [vtk-developers] PROPOSAL: Changing VTK's indentation style > > > > Hi folks, > > > > What would you think of changing VTK's indentation style from: > > > > if () > > { > > // .. > > } > > > > to > > > > if () > > { > > // ... > > } > > > > ? > > > > Our current style (modified Whitesmiths I am told) is used only by very > few projects, > > mostly related to VTK ones (ITK, CMake). It is poorly supported by some of > the newer editors > > that are widely popular (Sublime, TextMate etc.) and IMO foreign to the > new generation > > C++ developers. > > > > The style I propose is modified Allman style - with indentation changed > from 4 to 2 spaces. > > It is much more common. > > > > If approved by the community, we would change VTK wholesale. This should > not be > > an issue for history as git blame/annotate can be told to skip white > spaces. > > > > Best, > > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Thu Sep 10 09:41:56 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Thu, 10 Sep 2015 09:41:56 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: Steve, As far as ParaView is concerned, whatever VTK decides, ParaView will follow. For the most part, a ParaView developer is a VTK developer too, hence it's safe to assume that he/she is following this discussion and can voice his/her concerns, if any. Utkarsh On Wed, Sep 9, 2015 at 7:13 PM, Steve Pieper wrote: > Has anyone raised the idea of changing the ITK or ParView styles? I > suspect as separate projects they would have their own discussions. > > -Steve > > On Wed, Sep 9, 2015 at 6:41 PM, Andras Lasso wrote: > >> I would not worry too much about Slicer extensions. For example in our >> extensions we already use the usual indentation instead of VTK?s. >> >> >> >> Note that ITK, Paraview, etc. would need to be updated to the same style, >> too. >> >> >> >> Andras >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Steve Pieper >> *Sent:* September 9, 2015 6:27 PM >> *To:* David Gobbi >> *Cc:* VTK Developers ; Brad King < >> brad.king at kitware.com> >> *Subject:* Re: [vtk-developers] PROPOSAL: Changing VTK's indentation >> style >> >> >> >> I'd personally vote for: >> >> >> >> int func( int arg ) >> >> { >> >> // this code looks gorgeous! >> >> if ( condition ) { >> >> statement; >> >> } else { >> >> statement; >> >> } >> >> } >> >> >> >> But I'm also used to VTK's "unorthodox" style and don't really mind it. >> To be honest it makes it very clear when I'm looking at VTK code and when >> code has been written by novices vs old hands (and yes, sometimes I form >> opinions about likely code quality from that). >> >> >> >> I'd also like to point out that in Slicer our explicit style [1] is to >> copy VTK style for any code that inherits from VTK objects. So if VTK >> changes Slicer will have to also, and by implication all Slicer extensions >> should also change. This will create extra maintenance work and probably >> some confusion for our community (and I suspect other projects will have >> similar issues). >> >> >> >> Is the motivation for this change really worth introducing some busywork >> and confusion for people who use VTK? If yes, then +1. >> >> >> >> -Steve >> >> >> >> [1] >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide >> >> >> >> >> >> >> >> On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi >> wrote: >> >> Hi Brad, >> >> >> >> Even though I slightly prefer the inline "if () {" style, I can offer >> some arguments against it. >> >> >> >> 1) it doesn't work well for multi-line conditionals: >> >> >> >> for (std::vector::iterator iter = vec.begin(); >> >> iter != vec.end(); >> >> ++iter) { >> >> statements; >> >> } >> >> >> >> versus >> >> >> >> for (std::vector::iterator iter = vec.begin(); >> >> iter != vec.end(); >> >> ++iter) >> >> { >> >> statements; >> >> } >> >> >> >> 2) it's inherently inconsistent. This is demonstrated by the following >> Java-styled code that actually applies the style consistently: >> >> >> >> int myfunc(int x) { >> >> if (x == 0) { >> >> statements; >> >> } >> >> } >> >> >> >> Most C++ programmers (like myself) think the above is ridiculous, but >> really, why should a definition block be treated differently from a >> conditional block? >> >> >> >> In my opinion, putting the brace on the following line is nice because it >> is a simple, consistent rule that produces easily readable code. >> >> >> >> I'm a fan of compact code, but only when it is compactified according to >> my own tastes. Otherwise the compactification loses its value ;-) >> >> >> >> - David >> >> >> >> >> >> On Wed, Sep 9, 2015 at 3:29 PM, Brad King wrote: >> >> On 9/9/2015 3:41 PM, Brad King wrote: >> > if (...) { >> > ... >> > } else { >> > ... >> > } >> [snip] >> > if (...) >> > { >> > ... >> > } >> > else >> > { >> > ... >> > } >> >> There seems to be agreement that either of these is an improvement >> but that we should choose now which one to use. I'm sure one can >> find endless debates across the web about which one is best. Here >> are the main reasons I prefer the former over the latter: >> >> 1. Uses less vertical space. This is important when the content >> within the blocks is short. >> >> 2. The start and end of each logical block is aligned horizontally >> and can be matched vertically with nothing in the way: >> >> if (...) { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } else { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } >> >> This is important when the content within the blocks is long. >> >> 3. Distinguishes conditional and unconditional blocks: >> >> if (...) { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> Contrast this to the latter style where both look the same: >> >> if (...) >> { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> In the latter style one must read a line above the "{" to see >> whether it is a condition. This could be tricky if there is >> an unrelated f(...) call there. >> >> The former style is widely used in many projects and well-supported >> by editors. >> >> >> -Brad >> _______________________________________________ >> 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 >> >> >> > > > _______________________________________________ > 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 berk.geveci at kitware.com Thu Sep 10 09:51:42 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 10 Sep 2015 09:51:42 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <20150909134327.GA2859@megas.kitware.com> <55F08B77.1070804@kitware.com> <55F0A4AC.8080107@kitware.com> Message-ID: ITK and VTK are not tightly coupled so I don't see why we need to sync on the decision to change the coding style. It is hard enough to make these decisions in one community. I can't imagine trying to coordinate with other communities. If someone reading this would like to float the idea by the ITK community, please feel free to refer to this thread and the support this has gotten so far. ParaView and other projects like it that tightly couple with VTK would follow without any problems. They don't usually have their own independent coding styles anyway. On Wed, Sep 9, 2015 at 7:13 PM, Steve Pieper wrote: > Has anyone raised the idea of changing the ITK or ParView styles? I > suspect as separate projects they would have their own discussions. > > -Steve > > On Wed, Sep 9, 2015 at 6:41 PM, Andras Lasso wrote: > >> I would not worry too much about Slicer extensions. For example in our >> extensions we already use the usual indentation instead of VTK?s. >> >> >> >> Note that ITK, Paraview, etc. would need to be updated to the same style, >> too. >> >> >> >> Andras >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Steve Pieper >> *Sent:* September 9, 2015 6:27 PM >> *To:* David Gobbi >> *Cc:* VTK Developers ; Brad King < >> brad.king at kitware.com> >> *Subject:* Re: [vtk-developers] PROPOSAL: Changing VTK's indentation >> style >> >> >> >> I'd personally vote for: >> >> >> >> int func( int arg ) >> >> { >> >> // this code looks gorgeous! >> >> if ( condition ) { >> >> statement; >> >> } else { >> >> statement; >> >> } >> >> } >> >> >> >> But I'm also used to VTK's "unorthodox" style and don't really mind it. >> To be honest it makes it very clear when I'm looking at VTK code and when >> code has been written by novices vs old hands (and yes, sometimes I form >> opinions about likely code quality from that). >> >> >> >> I'd also like to point out that in Slicer our explicit style [1] is to >> copy VTK style for any code that inherits from VTK objects. So if VTK >> changes Slicer will have to also, and by implication all Slicer extensions >> should also change. This will create extra maintenance work and probably >> some confusion for our community (and I suspect other projects will have >> similar issues). >> >> >> >> Is the motivation for this change really worth introducing some busywork >> and confusion for people who use VTK? If yes, then +1. >> >> >> >> -Steve >> >> >> >> [1] >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide >> >> >> >> >> >> >> >> On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi >> wrote: >> >> Hi Brad, >> >> >> >> Even though I slightly prefer the inline "if () {" style, I can offer >> some arguments against it. >> >> >> >> 1) it doesn't work well for multi-line conditionals: >> >> >> >> for (std::vector::iterator iter = vec.begin(); >> >> iter != vec.end(); >> >> ++iter) { >> >> statements; >> >> } >> >> >> >> versus >> >> >> >> for (std::vector::iterator iter = vec.begin(); >> >> iter != vec.end(); >> >> ++iter) >> >> { >> >> statements; >> >> } >> >> >> >> 2) it's inherently inconsistent. This is demonstrated by the following >> Java-styled code that actually applies the style consistently: >> >> >> >> int myfunc(int x) { >> >> if (x == 0) { >> >> statements; >> >> } >> >> } >> >> >> >> Most C++ programmers (like myself) think the above is ridiculous, but >> really, why should a definition block be treated differently from a >> conditional block? >> >> >> >> In my opinion, putting the brace on the following line is nice because it >> is a simple, consistent rule that produces easily readable code. >> >> >> >> I'm a fan of compact code, but only when it is compactified according to >> my own tastes. Otherwise the compactification loses its value ;-) >> >> >> >> - David >> >> >> >> >> >> On Wed, Sep 9, 2015 at 3:29 PM, Brad King wrote: >> >> On 9/9/2015 3:41 PM, Brad King wrote: >> > if (...) { >> > ... >> > } else { >> > ... >> > } >> [snip] >> > if (...) >> > { >> > ... >> > } >> > else >> > { >> > ... >> > } >> >> There seems to be agreement that either of these is an improvement >> but that we should choose now which one to use. I'm sure one can >> find endless debates across the web about which one is best. Here >> are the main reasons I prefer the former over the latter: >> >> 1. Uses less vertical space. This is important when the content >> within the blocks is short. >> >> 2. The start and end of each logical block is aligned horizontally >> and can be matched vertically with nothing in the way: >> >> if (...) { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } else { >> ^ ... >> | ... >> | ... >> | ... >> | ... >> v ... >> } >> >> This is important when the content within the blocks is long. >> >> 3. Distinguishes conditional and unconditional blocks: >> >> if (...) { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> Contrast this to the latter style where both look the same: >> >> if (...) >> { >> // conditional block >> } >> >> { >> // unconditional block >> } >> >> In the latter style one must read a line above the "{" to see >> whether it is a condition. This could be tricky if there is >> an unrelated f(...) call there. >> >> The former style is widely used in many projects and well-supported >> by editors. >> >> >> -Brad >> _______________________________________________ >> 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 >> >> >> > > > _______________________________________________ > 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 Sep 10 10:49:43 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 10 Sep 2015 10:49:43 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: Two points Berk and I were just discussing regarding John's desire for looser restrictions in the case of modules that are maintained by specific groups: * code style in third party modules within vtk are pretty much wide open. The only requirements really are that the license is compatible and that it compiles on the dashboards (warnings can be suppressed even). The VTK code that calls the third party code needs to comply with VTK style obviously. * We are going to be building up the external module infrastructure which will introduce a structured and graded path to module integration. We'll need to come up with specific guidelines but we might expect that the further away from the "core" a module is, the less strict the style rule enforcement will be. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Sep 10, 2015 at 9:24 AM, Berk Geveci wrote: > I am still against your proposal John. For reference, it was this: > > > I would like to reserve the right to use my own coding style on the > contributed class(es) > > It was not changing VTK's style to something different. Looking at that > thread, it also looked like everyone that contributed to it except you were > against it. Also looking at this thread, it sounds like many people are > still against mixing multiple styles in the same codebase. > > Best, > -berk > > > On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. > wrote: > >> +lots >> >> >> >> Like the Scottish who say ?Anyone but England?, I would like to >> emphatically vote in favour of changing VTK?s code style to ?Anything, but >> what we have now?, it certainly can?t get worse. >> >> >> >> Yours >> >> >> >> JB >> >> PS. It feels like 2006! I made my views felt then (and many times >> previously), and Berk has criticised my views on it for the last 10 years, >> so I shan?t say any more! >> >> >> http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html >> >> >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Berk Geveci >> *Sent:* 09 September 2015 15:09 >> *To:* VTK Developers >> *Subject:* [vtk-developers] PROPOSAL: Changing VTK's indentation style >> >> >> >> Hi folks, >> >> >> >> What would you think of changing VTK's indentation style from: >> >> >> >> if () >> >> { >> >> // .. >> >> } >> >> >> >> to >> >> >> >> if () >> >> { >> >> // ... >> >> } >> >> >> >> ? >> >> >> >> Our current style (modified Whitesmiths I am told) is used only by very >> few projects, >> >> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >> of the newer editors >> >> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >> new generation >> >> C++ developers. >> >> >> >> The style I propose is modified Allman style - with indentation changed >> from 4 to 2 spaces. >> >> It is much more common. >> >> >> >> If approved by the community, we would change VTK wholesale. This should >> not be >> >> an issue for history as git blame/annotate can be told to skip white >> spaces. >> >> >> >> Best, >> >> -berk >> > > > _______________________________________________ > 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 Sep 10 11:00:14 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 11:00:14 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: I am a vtk and itk developer. My emacs configuration automatically indents according to the current itk and vtk indentation styles,I am a +1 for the change to vtk's style. But, I hope someone can provided a script or automatic git commit hook to provide the proper indentation. +1 Bill From biddisco at cscs.ch Thu Sep 10 11:46:48 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Thu, 10 Sep 2015 15:46:48 +0000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: Berk, I was not trying to re-propose my suggestion, just emphasising how much I dislike the current style. When I looked at the archives, I found this classic rant from 2001 on the same subject. 14 years I?ve been whining! http://public.kitware.com/pipermail/vtk-developers/2001-May/015906.html Watch out Berk - Now that Kitware has abandoned gerrit, and is changing code style, I might start start cleaning up my CV and looking for job openings ;) JB From: Berk Geveci > Date: Thursday 10 September 2015 15:24 To: cscs > Cc: VTK Developers > Subject: Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style I am still against your proposal John. For reference, it was this: > I would like to reserve the right to use my own coding style on the contributed class(es) It was not changing VTK's style to something different. Looking at that thread, it also looked like everyone that contributed to it except you were against it. Also looking at this thread, it sounds like many people are still against mixing multiple styles in the same codebase. Best, -berk On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. > wrote: +lots Like the Scottish who say ?Anyone but England?, I would like to emphatically vote in favour of changing VTK?s code style to ?Anything, but what we have now?, it certainly can?t get worse. Yours JB PS. It feels like 2006! I made my views felt then (and many times previously), and Berk has criticised my views on it for the last 10 years, so I shan?t say any more! http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: 09 September 2015 15:09 To: VTK Developers Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style Hi folks, What would you think of changing VTK's indentation style from: if () { // .. } to if () { // ... } ? Our current style (modified Whitesmiths I am told) is used only by very few projects, mostly related to VTK ones (ITK, CMake). It is poorly supported by some of the newer editors that are widely popular (Sublime, TextMate etc.) and IMO foreign to the new generation C++ developers. The style I propose is modified Allman style - with indentation changed from 4 to 2 spaces. It is much more common. If approved by the community, we would change VTK wholesale. This should not be an issue for history as git blame/annotate can be told to skip white spaces. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Sep 10 12:11:22 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 10 Sep 2015 12:11:22 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: :-) PS: We are hiring. PS2: So happy that Gerrit is gone. On Thu, Sep 10, 2015 at 11:46 AM, Biddiscombe, John A. wrote: > Berk, > > I was not trying to re-propose my suggestion, just emphasising how much I > dislike the current style. > > When I looked at the archives, I found this classic rant from 2001 on the > same subject. 14 years I?ve been whining! > http://public.kitware.com/pipermail/vtk-developers/2001-May/015906.html > > Watch out Berk - Now that Kitware has abandoned gerrit, and is changing > code style, I might start start cleaning up my CV and looking for job > openings ;) > > JB > > > From: Berk Geveci > Date: Thursday 10 September 2015 15:24 > To: cscs > Cc: VTK Developers > Subject: Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style > > I am still against your proposal John. For reference, it was this: > > > I would like to reserve the right to use my own coding style on the > contributed class(es) > > It was not changing VTK's style to something different. Looking at that > thread, it also looked like everyone that contributed to it except you were > against it. Also looking at this thread, it sounds like many people are > still against mixing multiple styles in the same codebase. > > Best, > -berk > > > On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. > wrote: > >> +lots >> >> >> >> Like the Scottish who say ?Anyone but England?, I would like to >> emphatically vote in favour of changing VTK?s code style to ?Anything, but >> what we have now?, it certainly can?t get worse. >> >> >> >> Yours >> >> >> >> JB >> >> PS. It feels like 2006! I made my views felt then (and many times >> previously), and Berk has criticised my views on it for the last 10 years, >> so I shan?t say any more! >> >> >> http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html >> >> >> >> >> >> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >> Behalf Of *Berk Geveci >> *Sent:* 09 September 2015 15:09 >> *To:* VTK Developers >> *Subject:* [vtk-developers] PROPOSAL: Changing VTK's indentation style >> >> >> >> Hi folks, >> >> >> >> What would you think of changing VTK's indentation style from: >> >> >> >> if () >> >> { >> >> // .. >> >> } >> >> >> >> to >> >> >> >> if () >> >> { >> >> // ... >> >> } >> >> >> >> ? >> >> >> >> Our current style (modified Whitesmiths I am told) is used only by very >> few projects, >> >> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >> of the newer editors >> >> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >> new generation >> >> C++ developers. >> >> >> >> The style I propose is modified Allman style - with indentation changed >> from 4 to 2 spaces. >> >> It is much more common. >> >> >> >> If approved by the community, we would change VTK wholesale. This should >> not be >> >> an issue for history as git blame/annotate can be told to skip white >> spaces. >> >> >> >> Best, >> >> -berk >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 10 12:39:42 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 12:39:42 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: I think I can set up my emacs profile to use either style based on the file name containing itk or vtk, +1 On Thu, Sep 10, 2015 at 11:00 AM, Bill Lorensen wrote: > I am a vtk and itk developer. My emacs configuration automatically > indents according to the current itk and vtk indentation styles,I am a > +1 for the change to vtk's style. But, I hope someone can provided a > script or automatic git commit hook to provide the proper indentation. > > +1 > > Bill -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Thu Sep 10 12:44:13 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 10 Sep 2015 10:44:13 -0600 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: This has inspired me to re-attempt the removal of all //BTX and //ETX markers (now obsolete) from the header files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 10 13:01:21 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 13:01:21 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: Once again, a +1 for a change, but I wish we could spend more cycles on this that have more impact like new algorithms, external contributions, code coverage, etc... In defense of the current vtk style (whitesmith) that so many people hate, according to wikipedia: Whitesmiths along with Allman have been the most common bracing styles with equal mind shares according to the Jargon File "Whitesmiths along with Allman have been the most common bracing styles with equal mind shares according to the Jargon File" and the advantages of Whitesmith are: The advantages of this style are similar to those of the Allman style in that blocks are clearly set apart from control statements. Another advantage is the alignment of the braces with the block that emphasizes the fact that the entire block is conceptually (as well as programmatically) a single compound statement. Furthermore, indenting the braces emphasizes that they are subordinate to the control statement. Another advantage of this style is that the ending brace no longer lines up with the statement, but instead with the opening brace. On Thu, Sep 10, 2015 at 12:44 PM, David Gobbi wrote: > This has inspired me to re-attempt the removal of all //BTX and //ETX > markers (now obsolete) from the header files. > > _______________________________________________ > 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 david.gobbi at gmail.com Thu Sep 10 13:13:35 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 10 Sep 2015 11:13:35 -0600 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: Hi Bill, I suspect this will have a positive impact on external contributions. The jargon file is ancient, there is no way that Whitesmith still has equal mind share. Other than VTK and ITK, what large projects (or companies) still use Whitesmith? - David On Thu, Sep 10, 2015 at 11:01 AM, Bill Lorensen wrote: > Once again, a +1 for a change, but I wish we could spend more cycles > on this that have more impact like new algorithms, external > contributions, code coverage, etc... > > In defense of the current vtk style (whitesmith) that so many people > hate, according to wikipedia: Whitesmiths along with Allman have been > the most common bracing styles with equal mind shares according to the > Jargon File > > "Whitesmiths along with Allman have been the most common bracing > styles with equal mind shares according to the Jargon File" > and the advantages of Whitesmith are: > > The advantages of this style are similar to those of the Allman style > in that blocks are clearly set apart from control statements. Another > advantage is the alignment of the braces with the block that > emphasizes the fact that the entire block is conceptually (as well as > programmatically) a single compound statement. Furthermore, indenting > the braces emphasizes that they are subordinate to the control > statement. Another advantage of this style is that the ending brace no > longer lines up with the statement, but instead with the opening > brace. > > On Thu, Sep 10, 2015 at 12:44 PM, David Gobbi > wrote: > > This has inspired me to re-attempt the removal of all //BTX and //ETX > > markers (now obsolete) from the header files. > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Thu Sep 10 13:14:40 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 10 Sep 2015 13:14:40 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: I was out on travel, and missed the party. I am with Ken, +1 for either style, I personally prefer if () { // .... } but will happily live with if () { // ... } as what we have now is terrible. I think consistency is important though, and we should avoid mixing styles, so -10 on that too ;-) I would love to see the back of the VTK style, I think it makes it harder to get new contributors on board. Also glad to see the back of Gerrit, I think there are far better things today - such as Gitlab and GitHub. Once we are done with this...C++11, Doxygen comments, and typed enums?!?! On Thu, Sep 10, 2015 at 12:39 PM, Bill Lorensen wrote: > I think I can set up my emacs profile to use either style based on the > file name containing itk or vtk, > > +1 > > > On Thu, Sep 10, 2015 at 11:00 AM, Bill Lorensen wrote: >> I am a vtk and itk developer. My emacs configuration automatically >> indents according to the current itk and vtk indentation styles,I am a >> +1 for the change to vtk's style. But, I hope someone can provided a >> script or automatic git commit hook to provide the proper indentation. >> >> +1 >> >> 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 warfield at crl.med.harvard.edu Thu Sep 10 13:21:11 2015 From: warfield at crl.med.harvard.edu (Simon Warfield) Date: Thu, 10 Sep 2015 13:21:11 -0400 Subject: [vtk-developers] brace style In-Reply-To: References: Message-ID: <55F1BC07.8080409@crl.med.harvard.edu> The original brace styles were also the best: http://public.kitware.com/pipermail/vtk-developers/2001-May/015916.html --Simon > > On Thu, Sep 10, 2015 at 11:46 AM, Biddiscombe, John A. > wrote: > >> Berk, >> >> I was not trying to re-propose my suggestion, just emphasising how much I >> dislike the current style. >> >> When I looked at the archives, I found this classic rant from 2001 on the >> same subject. 14 years I?ve been whining! >> http://public.kitware.com/pipermail/vtk-developers/2001-May/015906.html >> >> Watch out Berk - Now that Kitware has abandoned gerrit, and is changing >> code style, I might start start cleaning up my CV and looking for job >> openings ;) >> >> JB >> >> >> From: Berk Geveci >> Date: Thursday 10 September 2015 15:24 >> To: cscs >> Cc: VTK Developers >> Subject: Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style >> >> I am still against your proposal John. For reference, it was this: >> >>> I would like to reserve the right to use my own coding style on the >> contributed class(es) >> >> It was not changing VTK's style to something different. Looking at that >> thread, it also looked like everyone that contributed to it except you were >> against it. Also looking at this thread, it sounds like many people are >> still against mixing multiple styles in the same codebase. >> >> Best, >> -berk >> >> >> On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. >> wrote: >> >>> +lots >>> >>> >>> >>> Like the Scottish who say ?Anyone but England?, I would like to >>> emphatically vote in favour of changing VTK?s code style to ?Anything, but >>> what we have now?, it certainly can?t get worse. >>> >>> >>> >>> Yours >>> >>> >>> >>> JB >>> >>> PS. It feels like 2006! I made my views felt then (and many times >>> previously), and Berk has criticised my views on it for the last 10 years, >>> so I shan?t say any more! >>> >>> >>> http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html >>> >>> >>> >>> >>> >>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On >>> Behalf Of *Berk Geveci >>> *Sent:* 09 September 2015 15:09 >>> *To:* VTK Developers >>> *Subject:* [vtk-developers] PROPOSAL: Changing VTK's indentation style >>> >>> >>> >>> Hi folks, >>> >>> >>> >>> What would you think of changing VTK's indentation style from: >>> >>> >>> >>> if () >>> >>> { >>> >>> // .. >>> >>> } >>> >>> >>> >>> to >>> >>> >>> >>> if () >>> >>> { >>> >>> // ... >>> >>> } >>> >>> >>> >>> ? >>> >>> >>> >>> Our current style (modified Whitesmiths I am told) is used only by very >>> few projects, >>> >>> mostly related to VTK ones (ITK, CMake). It is poorly supported by some >>> of the newer editors >>> >>> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the >>> new generation >>> >>> C++ developers. >>> >>> >>> >>> The style I propose is modified Allman style - with indentation changed >>> from 4 to 2 spaces. >>> >>> It is much more common. >>> >>> >>> >>> If approved by the community, we would change VTK wholesale. This should >>> not be >>> >>> an issue for history as git blame/annotate can be told to skip white >>> spaces. >>> >>> >>> >>> Best, >>> >>> -berk >>> From bill.lorensen at gmail.com Thu Sep 10 13:21:34 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 13:21:34 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: David, You are correct. Whitesmiths was popular many years ago (when we first did vtk). It is time for a change. But I don't think it will have much impact on external contributions. VTK has many other quirks()aka styles) as do most large packages. Time to move forward... On Thu, Sep 10, 2015 at 1:13 PM, David Gobbi wrote: > Hi Bill, > > I suspect this will have a positive impact on external contributions. > > The jargon file is ancient, there is no way that Whitesmith still > has equal mind share. Other than VTK and ITK, what large > projects (or companies) still use Whitesmith? > > - David > > > On Thu, Sep 10, 2015 at 11:01 AM, Bill Lorensen > wrote: >> >> Once again, a +1 for a change, but I wish we could spend more cycles >> on this that have more impact like new algorithms, external >> contributions, code coverage, etc... >> >> In defense of the current vtk style (whitesmith) that so many people >> hate, according to wikipedia: Whitesmiths along with Allman have been >> the most common bracing styles with equal mind shares according to the >> Jargon File >> >> "Whitesmiths along with Allman have been the most common bracing >> styles with equal mind shares according to the Jargon File" >> and the advantages of Whitesmith are: >> >> The advantages of this style are similar to those of the Allman style >> in that blocks are clearly set apart from control statements. Another >> advantage is the alignment of the braces with the block that >> emphasizes the fact that the entire block is conceptually (as well as >> programmatically) a single compound statement. Furthermore, indenting >> the braces emphasizes that they are subordinate to the control >> statement. Another advantage of this style is that the ending brace no >> longer lines up with the statement, but instead with the opening >> brace. >> >> On Thu, Sep 10, 2015 at 12:44 PM, David Gobbi >> wrote: >> > This has inspired me to re-attempt the removal of all //BTX and //ETX >> > markers (now obsolete) from the header files. >> > >> > _______________________________________________ >> > 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 > > -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Thu Sep 10 13:24:53 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Sep 2015 13:24:53 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: <20150910172453.GA13945@megas.kitware.com> On Thu, Sep 10, 2015 at 13:14:40 -0400, Marcus D. Hanwell wrote: > Once we are done with this...C++11, Doxygen comments, and typed enums?!?! Oh dear. If anyone wants to take a whack, here's (some of) my VTK wish list: - CMake 3-based module system; - replace "T *foo = T::New(); /* ... */ foo->Delete();" patterns with "vtkNew foo;"; - increase use of std::algorithm (making a vtk*Iterator -> STL Iterator adaptor would help *wonders* here); - make file readers more robust (using the afl[1] fuzzer as a guide). --Ben [1]http://lcamtuf.coredump.cx/afl/ From bill.lorensen at gmail.com Thu Sep 10 13:36:48 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 13:36:48 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150910172453.GA13945@megas.kitware.com> References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> <20150910172453.GA13945@megas.kitware.com> Message-ID: Can we please put this to bed and concentrate on the 58 gitlab merge requests? Bill On Thu, Sep 10, 2015 at 1:24 PM, Ben Boeckel wrote: > On Thu, Sep 10, 2015 at 13:14:40 -0400, Marcus D. Hanwell wrote: >> Once we are done with this...C++11, Doxygen comments, and typed enums?!?! > > Oh dear. If anyone wants to take a whack, here's (some of) my VTK wish > list: > > - CMake 3-based module system; > - replace "T *foo = T::New(); /* ... */ foo->Delete();" patterns with > "vtkNew foo;"; > - increase use of std::algorithm (making a vtk*Iterator -> STL > Iterator adaptor would help *wonders* here); > - make file readers more robust (using the afl[1] fuzzer as a guide). > > --Ben > > [1]http://lcamtuf.coredump.cx/afl/ -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Thu Sep 10 13:45:45 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Sep 2015 13:45:45 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> <20150910172453.GA13945@megas.kitware.com> Message-ID: <20150910174545.GA1766@megas.kitware.com> On Thu, Sep 10, 2015 at 13:36:48 -0400, Bill Lorensen wrote: > Can we please put this to bed and concentrate on the 58 gitlab merge > requests? Happy coincidence, I did go through and look at all of them yesterday. A few were closed as duplicates/superceded, other "test foo" branches were closed, a few +1's were generated from it, and progress on others. --Ben From will.schroeder at kitware.com Thu Sep 10 13:55:51 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 10 Sep 2015 13:55:51 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: I'm agnostic to style (probably because I used Fortran-formatted punch cards at one time), however +100 on: On Thu, Sep 10, 2015 at 1:01 PM, Bill Lorensen wrote: > but I wish we could spend more cycles > on this that have more impact like new algorithms, external > contributions, code coverage, etc... > more and faster algorithms and better software process :-) W PS- Bill, how is the external module work coming along? We should get on the phone and sync up. Or breakfast late next week.... -- William J. Schroeder, PhD Kitware, Inc. 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 dave.demarle at kitware.com Thu Sep 10 14:09:50 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 10 Sep 2015 14:09:50 -0400 Subject: [vtk-developers] VTK 6.3.0 Message-ID: VTK 6.3 is ready. Release notes are at: http://www.kitware.com/blog/home/post/963 Thank you everyone who contributed their time to VTK! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 10 14:11:27 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 14:11:27 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> Message-ID: Remote modules are working and in vtk: http://www.vtk.org/Wiki/VTK/Remote_Modules' Breakfast late next week would be good. On Thu, Sep 10, 2015 at 1:55 PM, Will Schroeder wrote: > I'm agnostic to style (probably because I used Fortran-formatted punch cards > at one time), however +100 on: > > On Thu, Sep 10, 2015 at 1:01 PM, Bill Lorensen > wrote: >> >> but I wish we could spend more cycles >> on this that have more impact like new algorithms, external >> contributions, code coverage, etc... > > > more and faster algorithms and better software process :-) > > W > > PS- Bill, how is the external module work coming along? We should get on the > phone and sync up. Or breakfast late next week.... > > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Thu Sep 10 15:51:51 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 10 Sep 2015 15:51:51 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C7ECBF3@MBX210.d.ethz.ch> <20150910172453.GA13945@megas.kitware.com> Message-ID: OK. Let's go with: if () { // ... } as it will have minimal impact on our ability to use git blame/annotate easily. We'll make this happen on our end. We'll give warning a while before doing it because it will create conflicts when merging branches that predate the change. -berk On Thu, Sep 10, 2015 at 1:36 PM, Bill Lorensen wrote: > Can we please put this to bed and concentrate on the 58 gitlab merge > requests? > > Bill > > > > On Thu, Sep 10, 2015 at 1:24 PM, Ben Boeckel > wrote: > > On Thu, Sep 10, 2015 at 13:14:40 -0400, Marcus D. Hanwell wrote: > >> Once we are done with this...C++11, Doxygen comments, and typed > enums?!?! > > > > Oh dear. If anyone wants to take a whack, here's (some of) my VTK wish > > list: > > > > - CMake 3-based module system; > > - replace "T *foo = T::New(); /* ... */ foo->Delete();" patterns with > > "vtkNew foo;"; > > - increase use of std::algorithm (making a vtk*Iterator -> STL > > Iterator adaptor would help *wonders* here); > > - make file readers more robust (using the afl[1] fuzzer as a guide). > > > > --Ben > > > > [1]http://lcamtuf.coredump.cx/afl/ > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Sep 10 20:13:37 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 11 Sep 2015 10:13:37 +1000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style Message-ID: Hi Berk, Here is my two cents worth. Unfortunately the internet matter transporter is down again, So you will just have to put up with a picture :-) Yes they do exist and were in wide use until withdrawn from circulation. Given that the comments have been overwhelmingly positive about implementing a formatting change, select what you think is best and just do it. We'll fit in with whatever you think is best. Now that VTK 6.3 is out of the way I think now is the best time to do it for VTK 7.0. Then we can get on with improving VTK! Things to consider: 1) It would be nice if the formatting style is one of those already existing in the major IDE's in use, Visual Studio, XCode, QTCreator. Of course the existing one would be subject to simple changes such as replacing tabs with spaces and two white spaces instead of four. Those still using Vim and Emacs should be able to easily cope with these changes. SUblime Text should work well in this case too. 2) git blame needs to be able to cope with the changes. 3) The git hooks need changing. 4) All the existing code needs to be retroformatted. Presumably you will write a script to do this. It would be a good idea to add this script (python?) to Utilities so that the Slicer people and others can easily reformat their code if so desired. retroformat ... I think its a new word! Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoCents.jpg Type: image/jpeg Size: 81732 bytes Desc: not available URL: From ben.boeckel at kitware.com Thu Sep 10 21:16:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 10 Sep 2015 21:16:10 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: References: Message-ID: <20150911011610.GA29493@bronto-burt.dev.benboeckel.net> On Fri, Sep 11, 2015 at 10:13:37 +1000, Andrew Maclean wrote: > 2) git blame needs to be able to cope with the changes. git blame can be told to ignore whitespace-only changes to a line (-w). > 3) The git hooks need changing. In what way? We've never enforced brace-style using hooks. Or at least we don't now. > 4) All the existing code needs to be retroformatted. Presumably you will > write a script to do this. It would be a good idea to add this script > (python?) to Utilities so that the Slicer people and others can easily > reformat their code if so desired. Yeah, committing the tool would be good. --Ben From bill.lorensen at gmail.com Thu Sep 10 21:26:08 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 10 Sep 2015 21:26:08 -0400 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150911011610.GA29493@bronto-burt.dev.benboeckel.net> References: <20150911011610.GA29493@bronto-burt.dev.benboeckel.net> Message-ID: I changed my emacs to detect whether I'm editing a VTK or itk file and select the proper style. On Sep 10, 2015 9:17 PM, "Ben Boeckel" wrote: > On Fri, Sep 11, 2015 at 10:13:37 +1000, Andrew Maclean wrote: > > 2) git blame needs to be able to cope with the changes. > > git blame can be told to ignore whitespace-only changes to a line (-w). > > > 3) The git hooks need changing. > > In what way? We've never enforced brace-style using hooks. Or at least > we don't now. > > > 4) All the existing code needs to be retroformatted. Presumably you will > > write a script to do this. It would be a good idea to add this script > > (python?) to Utilities so that the Slicer people and others can easily > > reformat their code if so desired. > > Yeah, committing the tool would be good. > > --Ben > _______________________________________________ > 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 andrew.amaclean at gmail.com Thu Sep 10 22:37:45 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 11 Sep 2015 12:37:45 +1000 Subject: [vtk-developers] PROPOSAL: Changing VTK's indentation style In-Reply-To: <20150911011610.GA29493@bronto-burt.dev.benboeckel.net> References: <20150911011610.GA29493@bronto-burt.dev.benboeckel.net> Message-ID: Sorry I thought you did enforce the brace style using hooks ( I hadn't looked), if so then it is even easier! On Fri, Sep 11, 2015 at 11:16 AM, Ben Boeckel wrote: > On Fri, Sep 11, 2015 at 10:13:37 +1000, Andrew Maclean wrote: > > 2) git blame needs to be able to cope with the changes. > > git blame can be told to ignore whitespace-only changes to a line (-w). > > > 3) The git hooks need changing. > > In what way? We've never enforced brace-style using hooks. Or at least > we don't now. > > > 4) All the existing code needs to be retroformatted. Presumably you will > > write a script to do this. It would be a good idea to add this script > > (python?) to Utilities so that the Slicer people and others can easily > > reformat their code if so desired. > > Yeah, committing the tool would be good. > > --Ben > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Fri Sep 11 10:51:29 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 11 Sep 2015 10:51:29 -0400 Subject: [vtk-developers] HPCWire Reader's Choice Awards. Please vote for VTK! Message-ID: Hi folks, VTK have been nominated for HPCWire Reader's Choice Awards in the category of visualization: http://www.hpcwire.com/2015-hpcwire-readers-choice-awards/ We would really appreciate your support and your vote this year. 2015 has been a year of major advancement for VTK in the area of HPC. The most notable efforts towards next generation computing is VTK-m ( http://m.vtk.org/). This emerging effort, which significantly improves our ability to compute on GPUs and massively multi-core CPUs, will be our main infrastructure to support next generation supercomputers such as the upcoming Cori, Trinity, Summit, Sierra and Aurora, all of which feature massive parallelism through the use of GPUs of Intel Xeon Phi processors. We have also a number of other efforts, including vtkSMP, which aims to introduces multi-threaded parallelism and together with VTK-m help us close any performance holds on multi-core systems, Intel IPCC with TACC which focuses on better leveraging vector units on CPUs and last but not least our next generation OpenGL efforts which focus on significant rendering improvements on modern GPUs as well as Intel's upcoming OpenSWR software rendering library. As these technologies mature and are deployed over the next few months, expect major performance boost in VTK and ParaView. Thank you for your support. Berk for the VTK team -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Fri Sep 11 16:11:17 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Fri, 11 Sep 2015 16:11:17 -0400 Subject: [vtk-developers] Flying Edges In-Reply-To: References: Message-ID: FYI- vtkFlyingEdges2D and vtkFlyingEdges3D have been merged into VTK proper. Thanks to help from Rob, Sujin, Bill L., Utkarsh, Sankhesh and many others... We will be presenting a paper at LDAV 2015 in October. (Ask me for a preview copy of you are interested.) Benchmarking indicates this is a very fast isocontouring algorithm, especially if you have multiple cores your machine (without generating seams or requiring point merging...build VTK with TBB using vtkSMPTools). So far we've run it on 2048^3 volumes with up to 160 threads, it runs great. Like any new algorithm I'm sure there are warts and implementation issues, so I'd enjoy hearing feedback. Maybe someday we'll slip it under the hood of vtkContourFilter, but I want to make sure it is rock solid first. If you are really ambitious, there is room for further improvement in the implementation including parallelizing the prefix_sum (third pass), and in the fourth pass (decoupling the topology and geometry generation). I can tell you more if you are interested. Best, W On Sat, Jan 10, 2015 at 10:04 AM, Will Schroeder wrote: > Over the holidays I gave myself the gift of designing and implementing a > new contouring algorithm :-) To my utter delight and amazement I stumbled > upon a novel approach that is readily parallelizable and yet wicked fast in > serial mode as well. The algorithm (vtkFlyingEdges2D/vtkFlyingEdges3D) has > been pushed into gerrit for review if anyone is interested (FlyingEdges > branch). Consider this a work in progress, we are benchmarking and working > through parallel implementation details now. We are planning a paper > submission in the near future. > > TLDR Details > + As many of you know the VTK community is taking aim at seriously > reworking the system to better support parallel computing. Much of this > work is being led by Berk Geveci and his team. For example, Berk introduced > the vtkSMPTools into VTK about a year ago, and we are actively working with > some big name chip manufacturers, DOE Labs, research organizations, and > other customers/collaborators to get this ambitious undertaking done. > Hopefully individuals in this VTK community will also lend their > significant expertise as well. > + Under prodding by Berk, and inspired by Patrick O'Leary's "born > parallel" slogan to rethinking systems and algorithms for parallel > computing, the motivation was to take one of the most important > visualization algorithms (isocontouring) and see if we could redesign it > for emerging parallel approaches. > + The venerable Marching Cubes algorithm introduced the key idea that the > topology of an isosurface within a voxel can be captured with an index into > a simple, finite case table. Yet the implementation of the algorithm can be > slower than you might expect because, for example, on interior voxels, > voxel edges can be processed up to four times, and vertices visited eight > times (ignoring gradient calculations). Also the output mesh is dynamically > created: a priori the number of output points and triangles is unknown, > which means that memory resizing (realloc's) are required. Finally, the > algorithm is often implemented with a "locator" or hash table to prevent > the creation of duplicate points on shared voxel edges (the so-called point > merging problem). Not good for parallel computing. > + Ken Martin's extremely fast Synchronized Templates algorithm introduced > the notion of a "voxel axes" or "edge triad" which consists of the three > x-y-z voxel axes located at the voxel origin. This triad is moved through > the volume in such a way as to intersect each voxel edge only one time > (with special treatment on the +x+y+z volume boundaries). (An aside: Ken > wrote this like 15 years ago, it's been the VTK standard ever since. > Initially we filed a patent application [since abandoned] but that was > before we realized how stupid it is for an open source company to hold > patents. Live and learn :-)) > + Flying Edges builds on these concepts and introduces some novel ideas. > It is a 3-pass algorithm: the first two passes gather information about the > volume including "intersections" along x-edges, and the number of output > primitives and points. The final pass generates output into preallocated > arrays. Some of the key ideas include: > -- each pass traverses x-rows in the volume completely independently > meaning that it is readily parallelizable. > -- the case table is based on the four voxel x-edges (which can be easily > transformed to and from a vertex-based MC table). Because the cases are > edge based, the computation of cases is parallel separable. > -- The novel concept of "computational trimming" is used to avoid massive > amounts of work. Basically the fact that isosurfaces are topologically > smooth is combined with the results of the first pass (building > x-voxel-edge cases) to reason about where the isosurface can exist in the > volume. This very simple topological reasoning enables the algorithm to > skip portions of x-rows, entire x-rows, and even x-y slices very rapidly. > -- Some simple edge metadata is gathered for each x-row volume edge which > can be used to allocate and partition memory for separate threads to write > into without contention (i.e., no mutexes or locks). This metadata also > enables the algorithm to process the voxels along each x-row in such a way > as to synchronously increment the point ids and triangle ids without > requiring point merging or hashing. In fact, topology generation (i.e., > creating triangles) is completely independent from point/geometry > generation (i.e., interpolating point coordinates and attributes along > edges). > + Early results show a 2-5x speedup over Synchronized Templates (>10x over > vtkImageMarchingCubes) when running in serial. However, this is very data > dependent and I suspect compiler dependent since there is a lot of C++ > templating and in-lining going on (make sure to build optimized/release > mode). Anyway I am very excited because once the parallel loops are > functioning properly we should see much more performance improvement. The > scalability may be hampered however because data movement over the memory > bus may slow things up (computations are relatively modest compared to the > total data processed). We'll be benchmarking performance over the next > couple of months to see where we really are and of course we'll update this > community at that time. > + The memory overhead of the algorithm is roughly 2-bits per vertex. > However as implemented now I'm avoiding bit packing and just use a byte > (unsigned char) per vertex. > + Other interesting tidbits: > -- The basic algorithm is extremely simple to implement. Most of the > complications come from dealing with volume boundaries. It would be > possible to significantly reduce code complexity by either padding the > +x+y+z volume boundaries by a layer of voxels, or alternatively not > processing the outermost layer of voxels. > -- Because I am lazy, the algorithm reuses the MC case table as enumerated > in VTK (vtkMarchingCubesTriangleCases.h). However at instantiation the MC > table is converted to a Flying Edges edge-based case table. Also note that > the MC table as originally defined is for a left-handed coordinate system > (see the original paper). So reordering of triangles is required to make > sure that normals and triangle ordering is consistent. > -- On our radar is potential vectorization of operation like interpolation > across voxel edges. As you know some of the big hardware manufacturers are > really pushing this now and we'd like to learn how to best take advantage > of this emerging resource. > -- Probably the biggest downside of this algorithm is that is can produce > degenerate triangles (i.e., zero-area triangles in 3D, zero-length line > segments in 2D). The major reason is that when preallocating output memory, > we do so based on topological evaluation. However, during actual point > generation in degenerate cases (a degenerate case occurs when one of more > vertex scalar values == isocontour value) multiple intersection points can > occur at the vertex producing degeneracies. Since discarding a degenerate > triangle would mess up the output preallocation we can't just throw away > degenerate primitives. However I have already thought through a solution to > this problem but it is based on (spoiler alert) a much more complex case > table that enumerates 3-values per vertex: (<,==,>) when compared to the > isocontour value. This is a novel idea as well, mostly the academic > literature completely ignores the reality of degeneracies. Maybe next > holiday season we'll slip it into the algorithm..... > > Okay I've got to get back to the pointy-haired management stuff. But > please feel free to provide feedback, or offers of collaboration :-) In > particular we'd love support, either in funding or brainpower, to do even > more cool parallel processing stuff. Hoping to hear from you, and I hope > your coming year is as exciting as mine is looking to be! > > Best, > W > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -- William J. Schroeder, PhD Kitware, Inc. 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 bill.lorensen at gmail.com Sat Sep 12 13:43:20 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 12 Sep 2015 13:43:20 -0400 Subject: [vtk-developers] gitlab down? Message-ID: git pull fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP connection reset by peer From DLRdave at aol.com Sat Sep 12 15:59:50 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 12 Sep 2015 15:59:50 -0400 Subject: [vtk-developers] gitlab down? In-Reply-To: References: Message-ID: I can't see gitlab.kitware.com in the web browser right now either. On Saturday, September 12, 2015, Bill Lorensen wrote: > git pull > fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP > connection reset by peer > _______________________________________________ > 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 mathieu.westphal at kitware.com Sun Sep 13 13:35:22 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Sun, 13 Sep 2015 19:35:22 +0200 Subject: [vtk-developers] gitlab down? In-Reply-To: References: Message-ID: https://gitlab.kitware.com/vtk/vtk.git/ (notice the https ) seems to be working fine. Mathieu Westphal On Sat, Sep 12, 2015 at 9:59 PM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > I can't see gitlab.kitware.com in the web browser right now either. > > > On Saturday, September 12, 2015, Bill Lorensen > wrote: > >> git pull >> fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP >> connection reset by peer >> _______________________________________________ >> 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 mathieu.westphal at kitware.com Sun Sep 13 13:36:37 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Sun, 13 Sep 2015 19:36:37 +0200 Subject: [vtk-developers] gitlab down? In-Reply-To: References: Message-ID: Ho no, i'm sorry, it was only my cache. not working here. Mathieu Westphal On Sun, Sep 13, 2015 at 7:35 PM, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > https://gitlab.kitware.com/vtk/vtk.git/ (notice the https ) seems to be > working fine. > > Mathieu Westphal > > On Sat, Sep 12, 2015 at 9:59 PM, David Cole via vtk-developers < > vtk-developers at vtk.org> wrote: > >> I can't see gitlab.kitware.com in the web browser right now either. >> >> >> On Saturday, September 12, 2015, Bill Lorensen >> wrote: >> >>> git pull >>> fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP >>> connection reset by peer >>> _______________________________________________ >>> 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 DLRdave at aol.com Sun Sep 13 16:11:43 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 13 Sep 2015 16:11:43 -0400 Subject: [vtk-developers] gitlab down? In-Reply-To: References: Message-ID: Seems to be back up now. On Sunday, September 13, 2015, Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Ho no, i'm sorry, it was only my cache. not working here. > > Mathieu Westphal > > On Sun, Sep 13, 2015 at 7:35 PM, Mathieu Westphal < > mathieu.westphal at kitware.com > > wrote: > >> https://gitlab.kitware.com/vtk/vtk.git/ (notice the https ) seems to be >> working fine. >> >> Mathieu Westphal >> >> On Sat, Sep 12, 2015 at 9:59 PM, David Cole via vtk-developers < >> vtk-developers at vtk.org >> > wrote: >> >>> I can't see gitlab.kitware.com in the web browser right now either. >>> >>> >>> On Saturday, September 12, 2015, Bill Lorensen >> > wrote: >>> >>>> git pull >>>> fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP >>>> connection reset by peer >>>> _______________________________________________ >>>> 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 chaffra at gmail.com Mon Sep 14 08:46:17 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Mon, 14 Sep 2015 08:46:17 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 Message-ID: <55F6C199.1090208@gmail.com> Hi, I am getting a lot of undefined references when linking. I know it is not linking to MPI or the right MPI but I cannot see how. I have openmpi installed and mpicc is pointing to the openmpi version. Can any reproduce or help? Error is below Thanks, Chaffra Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool)': vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): undefined reference to `ompi_mpi_cxx_op_intercept' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const': vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): undefined reference to `MPI::Comm::Comm()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Graphcomm::Clone() const': vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): undefined reference to `MPI::Comm::Comm()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Cartcomm::Clone() const': vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): undefined reference to `MPI::Comm::Comm()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Intercomm::Merge(bool) const': vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): undefined reference to `MPI::Comm::Comm()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function `MPI::Intracomm::Create(MPI::Group const&) const': vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): undefined reference to `MPI::Comm::Comm()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): more undefined references to `MPI::Comm::Comm()' follow CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): undefined reference to ` MPI::Datatype::Free()' CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): undefined reference to `MPI::Win::Free()' collect2: error: ld returned 1 exit status IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target 'lib/libvtkIOAMR-6.3.so.1' failed make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 CMakeFiles/Makefile2:6388: recipe for target 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 Makefile:107: recipe for target 'all' failed make: *** [all] Error 2 From ben.boeckel at kitware.com Mon Sep 14 10:08:58 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 14 Sep 2015 10:08:58 -0400 Subject: [vtk-developers] gitlab down? In-Reply-To: References: Message-ID: <20150914140858.GA1460@megas.kitware.com> On Sat, Sep 12, 2015 at 13:43:20 -0400, Bill Lorensen wrote: > git pull > fatal: unable to access 'https://gitlab.kitware.com/vtk/vtk.git/': TCP > connection reset by peer So gitlab being down this weekend made buildbot unhappy. Some builds have been forced to rebuild already, but if your branch looks broken due to git or other strange failures, let me know your MR/branch name and I'll restart your builds. If your branch got skipped: $ git checkout $branch $ GIT_EDITOR=true git commit --amend $ git gitlab-push -f Will leave the branch as-is (changing the commit time on the last commit) and tickle buildbot to rerun your branch (this works in general as well). --Ben From utkarsh.ayachit at kitware.com Mon Sep 14 10:56:43 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 14 Sep 2015 10:56:43 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: <55F6C199.1090208@gmail.com> References: <55F6C199.1090208@gmail.com> Message-ID: Chaffra, Are you by any change using system HDF5? Utkarsh On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda wrote: > Hi, > > I am getting a lot of undefined references when linking. I know it is not > linking to MPI or the right MPI but I cannot see how. > I have openmpi installed and mpicc is pointing to the openmpi version. Can > any reproduce or help? Error is below > > Thanks, > Chaffra > > Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), > bool)': > vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): > undefined reference to `ompi_mpi_cxx_op_intercept' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const': > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): > undefined reference to `MPI::Comm::Comm()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Graphcomm::Clone() const': > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): > undefined reference to `MPI::Comm::Comm()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Cartcomm::Clone() const': > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): > undefined reference to `MPI::Comm::Comm()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Intercomm::Merge(bool) const': > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): > undefined reference to `MPI::Comm::Comm()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function > `MPI::Intracomm::Create(MPI::Group const&) const': > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): > undefined reference to `MPI::Comm::Comm()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: > (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): more > undefined references to `MPI::Comm::Comm()' follow > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): > undefined reference to ` MPI::Datatype::Free()' > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): > undefined reference to `MPI::Win::Free()' > collect2: error: ld returned 1 exit status > IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target > 'lib/libvtkIOAMR-6.3.so.1' failed > make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 > CMakeFiles/Makefile2:6388: recipe for target > 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed > make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 > Makefile:107: recipe for target 'all' failed > make: *** [all] Error 2 > > _______________________________________________ > 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 chaffra at gmail.com Mon Sep 14 11:49:09 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Mon, 14 Sep 2015 11:49:09 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: References: <55F6C199.1090208@gmail.com> Message-ID: <55F6EC75.4080304@gmail.com> Utkarsh, Yes I am: I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? Chaffra On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: > Chaffra, > > Are you by any change using system HDF5? > > Utkarsh > > On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda wrote: >> Hi, >> >> I am getting a lot of undefined references when linking. I know it is not >> linking to MPI or the right MPI but I cannot see how. >> I have openmpi installed and mpicc is pointing to the openmpi version. Can >> any reproduce or help? Error is below >> >> Thanks, >> Chaffra >> >> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), >> bool)': >> vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): >> undefined reference to `ompi_mpi_cxx_op_intercept' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const': >> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): >> undefined reference to `MPI::Comm::Comm()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Graphcomm::Clone() const': >> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): >> undefined reference to `MPI::Comm::Comm()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Cartcomm::Clone() const': >> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): >> undefined reference to `MPI::Comm::Comm()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Intercomm::Merge(bool) const': >> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): >> undefined reference to `MPI::Comm::Comm()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >> `MPI::Intracomm::Create(MPI::Group const&) const': >> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): >> undefined reference to `MPI::Comm::Comm()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: >> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): more >> undefined references to `MPI::Comm::Comm()' follow >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): >> undefined reference to ` MPI::Datatype::Free()' >> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): >> undefined reference to `MPI::Win::Free()' >> collect2: error: ld returned 1 exit status >> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target >> 'lib/libvtkIOAMR-6.3.so.1' failed >> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 >> CMakeFiles/Makefile2:6388: recipe for target >> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed >> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 >> Makefile:107: recipe for target 'all' failed >> make: *** [all] Error 2 >> >> _______________________________________________ >> 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 Mon Sep 14 14:04:53 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 14 Sep 2015 12:04:53 -0600 Subject: [vtk-developers] New automatic gitlab "release" checks Message-ID: I saw something new in kwrobot's content check message: Eligible for the 6.3.x release branch. Is this something that was just added? I like. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Sep 14 14:07:24 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 14 Sep 2015 14:07:24 -0400 Subject: [vtk-developers] New automatic gitlab "release" checks In-Reply-To: References: Message-ID: Yes very new. Ben has been working on the infrastructure for 6.x branch longterm maintenance. Happy now? ;) David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Sep 14, 2015 at 2:04 PM, David Gobbi wrote: > I saw something new in kwrobot's content check message: > > Eligible for the 6.3.x release branch. > > Is this something that was just added? I like. > > - David > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 14 14:16:30 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 14 Sep 2015 12:16:30 -0600 Subject: [vtk-developers] New automatic gitlab "release" checks In-Reply-To: References: Message-ID: On Mon, Sep 14, 2015 at 12:07 PM, David E DeMarle wrote: > Happy now? ;) > I'm positively overflowing with delight. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Sep 14 14:19:35 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 14 Sep 2015 14:19:35 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: <55F6EC75.4080304@gmail.com> References: <55F6C199.1090208@gmail.com> <55F6EC75.4080304@gmail.com> Message-ID: For starters, turn off USE_SYSTEM_HDF5 and then confirm it builds. Once that's confirmed, you can turn the flag back on and then update the HDF5 library variables to include the MPI variables as well. On Mon, Sep 14, 2015 at 11:49 AM, Chaffra Affouda wrote: > Utkarsh, > > Yes I am: > I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? > > Chaffra > > > On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: >> >> Chaffra, >> >> Are you by any change using system HDF5? >> >> Utkarsh >> >> On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda >> wrote: >>> >>> Hi, >>> >>> I am getting a lot of undefined references when linking. I know it is not >>> linking to MPI or the right MPI but I cannot see how. >>> I have openmpi installed and mpicc is pointing to the openmpi version. >>> Can >>> any reproduce or help? Error is below >>> >>> Thanks, >>> Chaffra >>> >>> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), >>> bool)': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): >>> undefined reference to `ompi_mpi_cxx_op_intercept' >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): >>> undefined reference to `MPI::Comm::Comm()' >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Graphcomm::Clone() const': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): >>> undefined reference to `MPI::Comm::Comm()' >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Cartcomm::Clone() const': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): >>> undefined reference to `MPI::Comm::Comm()' >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Intercomm::Merge(bool) const': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): >>> undefined reference to `MPI::Comm::Comm()' >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In function >>> `MPI::Intracomm::Create(MPI::Group const&) const': >>> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): >>> undefined reference to `MPI::Comm::Comm()' >>> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: >>> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): >>> more >>> undefined references to `MPI::Comm::Comm()' follow >>> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): >>> undefined reference to ` MPI::Datatype::Free()' >>> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): >>> undefined reference to `MPI::Win::Free()' >>> collect2: error: ld returned 1 exit status >>> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target >>> 'lib/libvtkIOAMR-6.3.so.1' failed >>> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 >>> CMakeFiles/Makefile2:6388: recipe for target >>> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed >>> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 >>> Makefile:107: recipe for target 'all' failed >>> make: *** [all] Error 2 >>> >>> _______________________________________________ >>> 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 ben.boeckel at kitware.com Mon Sep 14 15:14:27 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 14 Sep 2015 15:14:27 -0400 Subject: [vtk-developers] New automatic gitlab "release" checks In-Reply-To: References: Message-ID: <20150914191427.GA14465@megas.kitware.com> On Mon, Sep 14, 2015 at 12:04:53 -0600, David Gobbi wrote: > I saw something new in kwrobot's content check message: > > Eligible for the 6.3.x release branch. > > Is this something that was just added? I like. Yep. Much easier than clicking ~4 times and editing a URL[1] to see if branches are based on the right commits ;) . And going through the process to make that footnote shows that you're extending topics already merged, so this message is immensely helpful since that process would have shown a false-negative for your branch (and looking at git log, that's a *lot* more clicking to finally see the root with `release`. --Ben [1]My process: - click on the oldest commit on the branch; - click on the parent commit; - replace user's name with "vtk" in the URL; - expand list of names the commit is part of checking that `release` is there. From chaffra at gmail.com Mon Sep 14 15:21:27 2015 From: chaffra at gmail.com (Chaffra J. Affouda) Date: Mon, 14 Sep 2015 19:21:27 +0000 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: References: <55F6C199.1090208@gmail.com> <55F6EC75.4080304@gmail.com> Message-ID: Ok I did and it built. What hdf5/mpi variables do I need to update? Thanks, Chaffra On Mon, Sep 14, 2015, 14:19 Utkarsh Ayachit wrote: > For starters, turn off USE_SYSTEM_HDF5 and then confirm it builds. > Once that's confirmed, you can turn the flag back on and then update > the HDF5 library variables to include the MPI variables as well. > > On Mon, Sep 14, 2015 at 11:49 AM, Chaffra Affouda > wrote: > > Utkarsh, > > > > Yes I am: > > I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? > > > > Chaffra > > > > > > On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: > >> > >> Chaffra, > >> > >> Are you by any change using system HDF5? > >> > >> Utkarsh > >> > >> On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda > >> wrote: > >>> > >>> Hi, > >>> > >>> I am getting a lot of undefined references when linking. I know it is > not > >>> linking to MPI or the right MPI but I cannot see how. > >>> I have openmpi installed and mpicc is pointing to the openmpi version. > >>> Can > >>> any reproduce or help? Error is below > >>> > >>> Thanks, > >>> Chaffra > >>> > >>> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), > >>> bool)': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): > >>> undefined reference to `ompi_mpi_cxx_op_intercept' > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) > const': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): > >>> undefined reference to `MPI::Comm::Comm()' > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Graphcomm::Clone() const': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): > >>> undefined reference to `MPI::Comm::Comm()' > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Cartcomm::Clone() const': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): > >>> undefined reference to `MPI::Comm::Comm()' > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Intercomm::Merge(bool) const': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): > >>> undefined reference to `MPI::Comm::Comm()' > >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In > function > >>> `MPI::Intracomm::Create(MPI::Group const&) const': > >>> > >>> > vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): > >>> undefined reference to `MPI::Comm::Comm()' > >>> > >>> > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: > >>> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): > >>> more > >>> undefined references to `MPI::Comm::Comm()' follow > >>> > >>> > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): > >>> undefined reference to ` MPI::Datatype::Free()' > >>> > >>> > CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): > >>> undefined reference to `MPI::Win::Free()' > >>> collect2: error: ld returned 1 exit status > >>> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target > >>> 'lib/libvtkIOAMR-6.3.so.1' failed > >>> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 > >>> CMakeFiles/Makefile2:6388: recipe for target > >>> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed > >>> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 > >>> Makefile:107: recipe for target 'all' failed > >>> make: *** [all] Error 2 > >>> > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/vtk-developers > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Sep 14 16:34:46 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 14 Sep 2015 16:34:46 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: References: <55F6C199.1090208@gmail.com> <55F6EC75.4080304@gmail.com> Message-ID: Can you try if the attached patch addresses the issue? Thanks Utkarsh On Mon, Sep 14, 2015 at 3:21 PM, Chaffra J. Affouda wrote: > Ok I did and it built. What hdf5/mpi variables do I need to update? > > Thanks, > Chaffra > > > On Mon, Sep 14, 2015, 14:19 Utkarsh Ayachit > wrote: >> >> For starters, turn off USE_SYSTEM_HDF5 and then confirm it builds. >> Once that's confirmed, you can turn the flag back on and then update >> the HDF5 library variables to include the MPI variables as well. >> >> On Mon, Sep 14, 2015 at 11:49 AM, Chaffra Affouda >> wrote: >> > Utkarsh, >> > >> > Yes I am: >> > I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? >> > >> > Chaffra >> > >> > >> > On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: >> >> >> >> Chaffra, >> >> >> >> Are you by any change using system HDF5? >> >> >> >> Utkarsh >> >> >> >> On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I am getting a lot of undefined references when linking. I know it is >> >>> not >> >>> linking to MPI or the right MPI but I cannot see how. >> >>> I have openmpi installed and mpicc is pointing to the openmpi version. >> >>> Can >> >>> any reproduce or help? Error is below >> >>> >> >>> Thanks, >> >>> Chaffra >> >>> >> >>> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >> >>> const&), >> >>> bool)': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): >> >>> undefined reference to `ompi_mpi_cxx_op_intercept' >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) >> >>> const': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): >> >>> undefined reference to `MPI::Comm::Comm()' >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Graphcomm::Clone() const': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): >> >>> undefined reference to `MPI::Comm::Comm()' >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Cartcomm::Clone() const': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): >> >>> undefined reference to `MPI::Comm::Comm()' >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Intercomm::Merge(bool) const': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): >> >>> undefined reference to `MPI::Comm::Comm()' >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >> >>> function >> >>> `MPI::Intracomm::Create(MPI::Group const&) const': >> >>> >> >>> >> >>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): >> >>> undefined reference to `MPI::Comm::Comm()' >> >>> >> >>> >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: >> >>> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): >> >>> more >> >>> undefined references to `MPI::Comm::Comm()' follow >> >>> >> >>> >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): >> >>> undefined reference to ` MPI::Datatype::Free()' >> >>> >> >>> >> >>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): >> >>> undefined reference to `MPI::Win::Free()' >> >>> collect2: error: ld returned 1 exit status >> >>> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target >> >>> 'lib/libvtkIOAMR-6.3.so.1' failed >> >>> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 >> >>> CMakeFiles/Makefile2:6388: recipe for target >> >>> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed >> >>> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 >> >>> Makefile:107: recipe for target 'all' failed >> >>> make: *** [all] Error 2 >> >>> >> >>> _______________________________________________ >> >>> 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 -------------- A non-text attachment was scrubbed... Name: TemporaryFix.patch Type: text/x-patch Size: 406 bytes Desc: not available URL: From chaffra at gmail.com Tue Sep 15 18:23:05 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Tue, 15 Sep 2015 18:23:05 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: References: <55F6C199.1090208@gmail.com> <55F6EC75.4080304@gmail.com> Message-ID: <55F89A49.2040601@gmail.com> Thanks it does. On 09/14/2015 04:34 PM, Utkarsh Ayachit wrote: > Can you try if the attached patch addresses the issue? > > Thanks > Utkarsh > > On Mon, Sep 14, 2015 at 3:21 PM, Chaffra J. Affouda wrote: >> Ok I did and it built. What hdf5/mpi variables do I need to update? >> >> Thanks, >> Chaffra >> >> >> On Mon, Sep 14, 2015, 14:19 Utkarsh Ayachit >> wrote: >>> For starters, turn off USE_SYSTEM_HDF5 and then confirm it builds. >>> Once that's confirmed, you can turn the flag back on and then update >>> the HDF5 library variables to include the MPI variables as well. >>> >>> On Mon, Sep 14, 2015 at 11:49 AM, Chaffra Affouda >>> wrote: >>>> Utkarsh, >>>> >>>> Yes I am: >>>> I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? >>>> >>>> Chaffra >>>> >>>> >>>> On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: >>>>> Chaffra, >>>>> >>>>> Are you by any change using system HDF5? >>>>> >>>>> Utkarsh >>>>> >>>>> On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I am getting a lot of undefined references when linking. I know it is >>>>>> not >>>>>> linking to MPI or the right MPI but I cannot see how. >>>>>> I have openmpi installed and mpicc is pointing to the openmpi version. >>>>>> Can >>>>>> any reproduce or help? Error is below >>>>>> >>>>>> Thanks, >>>>>> Chaffra >>>>>> >>>>>> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>> const&), >>>>>> bool)': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): >>>>>> undefined reference to `ompi_mpi_cxx_op_intercept' >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) >>>>>> const': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): >>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Graphcomm::Clone() const': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): >>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Cartcomm::Clone() const': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): >>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Intercomm::Merge(bool) const': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): >>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>> function >>>>>> `MPI::Intracomm::Create(MPI::Group const&) const': >>>>>> >>>>>> >>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): >>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>> >>>>>> >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: >>>>>> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): >>>>>> more >>>>>> undefined references to `MPI::Comm::Comm()' follow >>>>>> >>>>>> >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): >>>>>> undefined reference to ` MPI::Datatype::Free()' >>>>>> >>>>>> >>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): >>>>>> undefined reference to `MPI::Win::Free()' >>>>>> collect2: error: ld returned 1 exit status >>>>>> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target >>>>>> 'lib/libvtkIOAMR-6.3.so.1' failed >>>>>> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 >>>>>> CMakeFiles/Makefile2:6388: recipe for target >>>>>> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed >>>>>> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 >>>>>> Makefile:107: recipe for target 'all' failed >>>>>> make: *** [all] Error 2 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 chaffra at gmail.com Tue Sep 15 18:30:07 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Tue, 15 Sep 2015 18:30:07 -0400 Subject: [vtk-developers] opengl mixed with opengl2 Message-ID: <55F89BEF.1070908@gmail.com> Hello, I built vtk 6.3 with the following options below to use the old OpenGL backend. The problem is that I am getting some opengl2 modules mixed in. When linking to VTK, the ${VTK_LIBRARIES} contains some opengl2 dependent modules that were not built. So the linker is giving me errors: /usr/bin/ld: cannot find -lvtkRenderingVolumeOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingOpenGL2 /usr/bin/ld: cannot find -lvtkglew /usr/bin/ld: cannot find -lvtkDomainsChemistryOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingContextOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingVolumeOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingOpenGL2 /usr/bin/ld: cannot find -lvtkglew /usr/bin/ld: cannot find -lvtkDomainsChemistryOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingContextOpenGL2 VTK_LIBRARIES = vtkImagingFourier;vtkImagingCore;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkCommonExecutionModel;/usr/lib/x86_64-linux-gnu/libjpeg.so;vtkRenderingGL2PS;vtkRenderingContextOpenGL;vtkRenderingContext2D;vtkRenderingCore;vtkCommonColor;vtkFiltersExtraction;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkalglib;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;/usr/lib/x86_64-linux-gnu/libfreetype.so;/usr/lib/x86_64-linux-gnu/libz.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;/usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libtiff.so;/usr/lib/libgl2ps.so;vtkIOEnSight;vtkIOInfovis;vtkIOLegacy;vtkIOXML;vtkIOGeometry;vtkIOXMLParser;/usr/lib/x86_64-linux-gnu/libexpat.so;vtkInfovisCore;/usr/lib/x86_64-linux-gnu/libxml2.so;vtkRenderingImage;vtkChartsCore;vtkFiltersVerdict;verdict;vtkGUISupportQtOpenGL;vtkGUISupportQt;vtkInteractionStyle;vtkFiltersAMR;vtkParallelCore;vtkViewsContext2D;vtkViewsCore;vtkInteractionWidgets;vtkFiltersHybrid;vtkImagingSources;vtkFiltersModeling;vtkImagingGeneral;vtkRenderingAnnotation;vtkImagingColor;vtkRenderingVolume;vtkIOAMR;/usr/lib/x86_64-linux-gnu/libhdf5.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libhdf5_hl.so;/usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libhwloc.so;/usr/lib/libmpi_cxx.so;vtkRenderingVolumeOpenGL2;vtkRenderingOpenGL2;vtkglew;vtkFiltersSMP;vtkIOMINC;vtkNetCDF;vtkNetCDF_cxx;vtkIOImport;vtkIOExport;vtkRenderingLabel;vtkImagingStencil;vtkFiltersParallelGeometry;vtkParallelMPI;vtkImagingStatistics;vtkGUISupportQtSQL;vtkIOSQL;vtksqlite;vtkIOMovie;/usr/lib/x86_64-linux-gnu/libtheoraenc.so;/usr/lib/x86_64-linux-gnu/libtheoradec.so;/usr/lib/x86_64-linux-gnu/libogg.so;vtkRenderingLOD;vtkFiltersSelection;vtkIOMPIImage;vtkIOParallel;vtkFiltersParallel;vtkIONetCDF;vtkexoIIc;vtkjsoncpp;vtkFiltersParallelImaging;vtkFiltersImaging;vtkImagingMorphological;vtkRenderingQt;vtkFiltersTexture;vtkFiltersHyperTree;vtkDomainsChemistry;vtkParallelMPI4Py;/usr/lib/x86_64-linux-gnu/libpython2.7.so;vtkFiltersPython;vtkWrappingPythonCore;vtkWrappingTools;vtkIOPLY;vtkIOParallelXML;vtkRenderingLIC;vtkFiltersProgrammable;vtkIOExodus;vtkFiltersParallelMPI;vtkInfovisLayout;vtkFiltersFlowPaths;vtkViewsInfovis;vtkIOMPIParallel;vtkViewsQt;vtkDomainsChemistryOpenGL2;vtkViewsGeovis;vtkGeovisCore;vtkproj4;vtkRenderingContextOpenGL2;vtkIOVideo;vtkGUISupportQtWebkit;vtkFiltersGeneric;vtkImagingMath;vtkIOLSDyna;vtkInteractionImage;vtkIOParallelNetCDF;vtkRenderingVolumeOpenGL -DCMAKE_BUILD_TYPE=Release -D BUILD_TESTING=OFF -D BUILD_SHARED_LIBS=ON -D VTK_WRAP_PYTHON=ON -DVTK_WRAP_JAVA=OFF -DVTK_USE_TK:BOOL=ON -DVTK_QT_VERSION=4 -DVTK_USE_SYSTEM_EXPAT=ON -DVTK_USE_SYSTEM_FREETYPE=ON -DVTK_USE_SYSTEM_GL2PS=ON -DVTK_USE_SYSTEM_HDF5=ON -DVTK_USE_SYSTEM_JPEG=ON -DVTK_USE_SYSTEM_LIBXML2=ON -DVTK_USE_SYSTEM_OGGTHEORA=ON -DVTK_USE_SYSTEM_PNG=ON -DVTK_USE_SYSTEM_TIFF=ON -DVTK_USE_SYSTEM_ZLIB=ON -DVTK_Group_Imaging=ON -DVTK_Group_MPI=ON -DVTK_Group_Qt=ON -DVTK_Group_Tk=ON -DVTK_Group_Views=ON -DVTK_BUILD_ALL_MODULES=OFF -DMPI_CXX_INCLUDE_PATH="/usr/include/mpi" -DVTK_MAKE_INSTANTIATORS=ON -DVTK_RENDERING_BACKEND:STRING=OpenGL From ben.boeckel at kitware.com Tue Sep 15 18:51:01 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 15 Sep 2015 18:51:01 -0400 Subject: [vtk-developers] [HEADSUP] GCC5 builder Message-ID: <20150915225101.GA19091@megas.khq.kitware.com> Hi! I've updated the `megas` buildbot machine to Fedora 23, so there is now a GCC5 builder running (5.1.1 currently, but 5.2.1 is queued as an update). If anyone sees weird failures related to GCC 5, let me know. I expect it mostly to be related to C++11. Thanks, --Ben From chaffra at gmail.com Wed Sep 16 10:02:18 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Wed, 16 Sep 2015 10:02:18 -0400 Subject: [vtk-developers] opengl mixed with opengl2 Message-ID: <55F9766A.6040803@gmail.com> Never mind. It's working now. Must have been some residual installation files. After deleting all installed files and cleaning build directory it seems to work. Thanks, Chaffra ---- Hello, I built vtk 6.3 with the following options below to use the old OpenGL backend. The problem is that I am getting some opengl2 modules mixed in. When linking to VTK, the ${VTK_LIBRARIES} contains some opengl2 dependent modules that were not built. So the linker is giving me errors: /usr/bin/ld: cannot find -lvtkRenderingVolumeOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingOpenGL2 /usr/bin/ld: cannot find -lvtkglew /usr/bin/ld: cannot find -lvtkDomainsChemistryOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingContextOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingVolumeOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingOpenGL2 /usr/bin/ld: cannot find -lvtkglew /usr/bin/ld: cannot find -lvtkDomainsChemistryOpenGL2 /usr/bin/ld: cannot find -lvtkRenderingContextOpenGL2 VTK_LIBRARIES = vtkImagingFourier;vtkImagingCore;vtkCommonDataModel;vtkCommonMath;vtkCommonCore;vtksys;vtkCommonMisc;vtkCommonSystem;vtkCommonTransforms;vtkCommonExecutionModel;/usr/lib/x86_64-linux-gnu/libjpeg.so;vtkRenderingGL2PS;vtkRenderingContextOpenGL;vtkRenderingContext2D;vtkRenderingCore;vtkCommonColor;vtkFiltersExtraction;vtkFiltersCore;vtkFiltersGeneral;vtkCommonComputationalGeometry;vtkFiltersStatistics;vtkalglib;vtkFiltersGeometry;vtkFiltersSources;vtkRenderingFreeType;/usr/lib/x86_64-linux-gnu/libfreetype.so;/usr/lib/x86_64-linux-gnu/libz.so;vtkftgl;vtkRenderingOpenGL;vtkImagingHybrid;vtkIOImage;vtkDICOMParser;vtkIOCore;vtkmetaio;/usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libtiff.so;/usr/lib/libgl2ps.so;vtkIOEnSight;vtkIOInfovis;vtkIOLegacy;vtkIOXML;vtkIOGeometry;vtkIOXMLParser;/usr/lib/x86_64-linux-gnu/libexpat.so;vtkInfovisCore;/usr/lib/x86_64-linux-gnu/libxml2.so;vtkRenderingImage;vtkChartsCore;vtkFiltersVerdict;verdict;vtkGUISupportQtOpenGL;vtkGUISupportQt;vtkInt eractionStyle;vtkFiltersAMR;vtkParallelCore;vtkViewsContext2D;vtkViewsCore;vtkInteractionWidgets;vtkFiltersHybrid;vtkImagingSources;vtkFiltersModeling;vtkImagingGeneral;vtkRenderingAnnotation;vtkImagingColor;vtkRenderingVolume;vtkIOAMR;/usr/lib/x86_64-linux-gnu/libhdf5.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libhdf5_hl.so;/usr/lib/libmpi.so;/usr/lib/x86_64-linux-gnu/libhwloc.so;/usr/lib/libmpi_cxx.so;vtkRenderingVolumeOpenGL2;vtkRenderingOpenGL2;vtkglew;vtkFiltersSMP;vtkIOMINC;vtkNetCDF;vtkNetCDF_cxx;vtkIOImport;vtkIOExport;vtkRenderingLabel;vtkImagingStencil;vtkFiltersParallelGeometry;vtkParallelMPI;vtkImagingStatistics;vtkGUISupportQtSQL;vtkIOSQL;vtksqlite;vtkIOMovie;/usr/lib/x86_64-linux-gnu/libtheoraenc.so;/usr/lib/x86_64-linux-gnu/libtheoradec.so;/usr/lib/x86_64-linux-gnu/libogg.so;vtkRenderingLOD;vtkFiltersSelection;vtkIOMPIImage;vtkIOParallel;vtkFiltersParallel;vtkIONetCDF;vtkexoI Ic;vtkjsoncpp;vtkFiltersParallelImaging;vtkFiltersImaging;vtkImagingMorphological;vtkRenderingQt;vtkFiltersTexture;vtkFiltersHyperTree;vtkDomainsChemistry;vtkParallelMPI4Py;/usr/lib/x86_64-linux-gnu/libpython2.7.so;vtkFiltersPython;vtkWrappingPythonCore;vtkWrappingTools;vtkIOPLY;vtkIOParallelXML;vtkRenderingLIC;vtkFiltersProgrammable;vtkIOExodus;vtkFiltersParallelMPI;vtkInfovisLayout;vtkFiltersFlowPaths;vtkViewsInfovis;vtkIOMPIParallel;vtkViewsQt;vtkDomainsChemistryOpenGL2;vtkViewsGeovis;vtkGeovisCore;vtkproj4;vtkRenderingContextOpenGL2;vtkIOVideo;vtkGUISupportQtWebkit;vtkFiltersGeneric;vtkImagingMath;vtkIOLSDyna;vtkInteractionImage;vtkIOParallelNetCDF;vtkRenderingVolumeOpenGL -DCMAKE_BUILD_TYPE=Release -D BUILD_TESTING=OFF -D BUILD_SHARED_LIBS=ON -D VTK_WRAP_PYTHON=ON -DVTK_WRAP_JAVA=OFF -DVTK_USE_TK:BOOL=ON -DVTK_QT_VERSION=4 -DVTK_USE_SYSTEM_EXPAT=ON -DVTK_USE_SYSTEM_FREETYPE=ON -DVTK_USE_SYSTEM_GL2PS=ON -DVTK_USE_SYSTEM_HDF5=ON -DVTK_USE_SYSTEM_JPEG=ON -DVTK_USE_SYSTEM_LIBXML2=ON -DVTK_USE_SYSTEM_OGGTHEORA=ON -DVTK_USE_SYSTEM_PNG=ON -DVTK_USE_SYSTEM_TIFF=ON -DVTK_USE_SYSTEM_ZLIB=ON -DVTK_Group_Imaging=ON -DVTK_Group_MPI=ON -DVTK_Group_Qt=ON -DVTK_Group_Tk=ON -DVTK_Group_Views=ON -DVTK_BUILD_ALL_MODULES=OFF -DMPI_CXX_INCLUDE_PATH="/usr/include/mpi" -DVTK_MAKE_INSTANTIATORS=ON -DVTK_RENDERING_BACKEND:STRING=OpenGL From chaffra at gmail.com Wed Sep 16 11:29:51 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Wed, 16 Sep 2015 11:29:51 -0400 Subject: [vtk-developers] undefined reference to `__imp_SymSetOptions' Message-ID: <55F98AEF.4060703@gmail.com> Hi, When building with MinGW/MSYS2 I am getting the linkage error below. II am using the trunk version (VTK6.3). The build used to work no problem on MinGW. Looks like there is a missing library to link to on MINGW. Any help would be appreciated. Linking CXX shared library ../../bin/libvtkCommonCore-6.3.dll CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x848): undefined reference to `__imp_SymSetOptions' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x859): undefined reference to `__imp_SymInitialize' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x89d): undefined reference to `__imp_SymFromAddr' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x8a9): undefined reference to `__imp_SymGetLineFromAddr64' ----cmake configure------------------------ -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF -DBUILD_DOCUMENTATION=OFF -DBUILD_SHARED_LIBS=ON -DVTK_WRAP_PYTHON=ON -DVTK_WRAP_JAVA=OFF -DVTK_USE_TK:BOOL=ON -DVTK_QT_VERSION=4 -DVTK_USE_SYSTEM_EXPAT=ON -DVTK_USE_SYSTEM_FREETYPE=ON -DVTK_USE_SYSTEM_GL2PS=ON -DVTK_USE_SYSTEM_HDF5=ON -DVTK_USE_SYSTEM_JPEG=ON -DVTK_USE_SYSTEM_LIBXML2=ON -DVTK_USE_SYSTEM_OGGTHEORA=ON -DVTK_USE_SYSTEM_PNG=ON -DVTK_USE_SYSTEM_TIFF=ON -DVTK_USE_SYSTEM_ZLIB=ON -DVTK_USE_SYSTEM_JSONCPP=ON -DVTK_USE_SYSTEM_NETCDF=OFF -DVTK_Group_Imaging=ON -DVTK_Group_MPI=OFF -DVTK_Group_Qt=ON -DVTK_Group_Tk=ON -DVTK_Group_Views=ON -DVTK_Group_Rendering=ON -DVTK_Group_StandAlone=ON -DVTK_Group_Web=OFF -DVTK_BUILD_ALL_MODULES=OFF -DVTK_MAKE_INSTANTIATORS=ON -DVTK_RENDERING_BACKEND:STRING=OpenGL From chaffra at gmail.com Wed Sep 16 11:52:45 2015 From: chaffra at gmail.com (Chaffra Affouda) Date: Wed, 16 Sep 2015 11:52:45 -0400 Subject: [vtk-developers] undefined reference to `__imp_SymSetOptions' Message-ID: <55F9904D.1090808@gmail.com> I think it has to do with #pragma comment(lib, "Dbghelp.lib") which works with MSVS but not MINGW. Where should I add -ldbghelp in the cmake structure? ---- Hi, When building with MinGW/MSYS2 I am getting the linkage error below. II am using the trunk version (VTK6.3). The build used to work no problem on MinGW. Looks like there is a missing library to link to on MINGW. Any help would be appreciated. Linking CXX shared library ../../bin/libvtkCommonCore-6.3.dll CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x848): undefined reference to `__imp_SymSetOptions' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x859): undefined reference to `__imp_SymInitialize' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x89d): undefined reference to `__imp_SymFromAddr' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWin32OutputWindow.cxx:(.text +0x8a9): undefined reference to `__imp_SymGetLineFromAddr64' ----cmake configure------------------------ -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF -DBUILD_DOCUMENTATION=OFF -DBUILD_SHARED_LIBS=ON -DVTK_WRAP_PYTHON=ON -DVTK_WRAP_JAVA=OFF -DVTK_USE_TK:BOOL=ON -DVTK_QT_VERSION=4 -DVTK_USE_SYSTEM_EXPAT=ON -DVTK_USE_SYSTEM_FREETYPE=ON -DVTK_USE_SYSTEM_GL2PS=ON -DVTK_USE_SYSTEM_HDF5=ON -DVTK_USE_SYSTEM_JPEG=ON -DVTK_USE_SYSTEM_LIBXML2=ON -DVTK_USE_SYSTEM_OGGTHEORA=ON -DVTK_USE_SYSTEM_PNG=ON -DVTK_USE_SYSTEM_TIFF=ON -DVTK_USE_SYSTEM_ZLIB=ON -DVTK_USE_SYSTEM_JSONCPP=ON -DVTK_USE_SYSTEM_NETCDF=OFF -DVTK_Group_Imaging=ON -DVTK_Group_MPI=OFF -DVTK_Group_Qt=ON -DVTK_Group_Tk=ON -DVTK_Group_Views=ON -DVTK_Group_Rendering=ON -DVTK_Group_StandAlone=ON -DVTK_Group_Web=OFF -DVTK_BUILD_ALL_MODULES=OFF -DVTK_MAKE_INSTANTIATORS=ON -DVTK_RENDERING_BACKEND:STRING=OpenGL From ben.boeckel at kitware.com Wed Sep 16 13:50:29 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 16 Sep 2015 13:50:29 -0400 Subject: [vtk-developers] [ANN] Gitlab expected downtime today Message-ID: <20150916175029.GA377@megas.khq.kitware.com> Hi, Gitlab (and buildbot) will be down for a short time today while we upgrade the VM it is running on to have more resources. Expected downtime is about 5 to 15 minutes. Thanks, --Ben From ben.boeckel at kitware.com Wed Sep 16 15:51:02 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 16 Sep 2015 15:51:02 -0400 Subject: [vtk-developers] [ANN] Gitlab expected downtime today In-Reply-To: <20150916175029.GA377@megas.khq.kitware.com> References: <20150916175029.GA377@megas.khq.kitware.com> Message-ID: <20150916195102.GG29564@megas.khq.kitware.com> On Wed, Sep 16, 2015 at 13:50:29 -0400, Ben Boeckel wrote: > Gitlab (and buildbot) will be down for a short time today while we upgrade the > VM it is running on to have more resources. > > Expected downtime is about 5 to 15 minutes. All set. --Ben From ken.martin at kitware.com Wed Sep 16 17:16:44 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 16 Sep 2015 17:16:44 -0400 Subject: [vtk-developers] undefined reference to `__imp_SymSetOptions' In-Reply-To: <55F9904D.1090808@gmail.com> References: <55F9904D.1090808@gmail.com> Message-ID: <77507b5fd0234ede82bb2bfcb36f6cdd@mail.gmail.com> That is my bad. I was using that code to help debug some OpenGL issues and it seemed like useful code (nicely print out a stack trace whenever you want). So I tried leaving it in there worrying that it would cause an issue. I was originally going to leave it in as a comment block :-) but I hate doing that. Looks like MINGW was the issue. I'll yank it as it is not used by VTK currently. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Chaffra Affouda Sent: Wednesday, September 16, 2015 11:53 AM To: VTK Developers Subject: [vtk-developers] undefined reference to `__imp_SymSetOptions' I think it has to do with #pragma comment(lib, "Dbghelp.lib") which works with MSVS but not MINGW. Where should I add -ldbghelp in the cmake structure? ---- Hi, When building with MinGW/MSYS2 I am getting the linkage error below. II am using the trunk version (VTK6.3). The build used to work no problem on MinGW. Looks like there is a missing library to link to on MINGW. Any help would be appreciated. Linking CXX shared library ../../bin/libvtkCommonCore-6.3.dll CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWi n32OutputWindow.cxx:(.text +0x848): undefined reference to `__imp_SymSetOptions' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWi n32OutputWindow.cxx:(.text +0x859): undefined reference to `__imp_SymInitialize' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWi n32OutputWindow.cxx:(.text +0x89d): undefined reference to `__imp_SymFromAddr' CMakeFiles/vtkCommonCore.dir/objects.a(vtkWin32OutputWindow.cxx.obj):vtkWi n32OutputWindow.cxx:(.text +0x8a9): undefined reference to `__imp_SymGetLineFromAddr64' ----cmake configure------------------------ -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF -DBUILD_DOCUMENTATION=OFF -DBUILD_SHARED_LIBS=ON -DVTK_WRAP_PYTHON=ON -DVTK_WRAP_JAVA=OFF -DVTK_USE_TK:BOOL=ON -DVTK_QT_VERSION=4 -DVTK_USE_SYSTEM_EXPAT=ON -DVTK_USE_SYSTEM_FREETYPE=ON -DVTK_USE_SYSTEM_GL2PS=ON -DVTK_USE_SYSTEM_HDF5=ON -DVTK_USE_SYSTEM_JPEG=ON -DVTK_USE_SYSTEM_LIBXML2=ON -DVTK_USE_SYSTEM_OGGTHEORA=ON -DVTK_USE_SYSTEM_PNG=ON -DVTK_USE_SYSTEM_TIFF=ON -DVTK_USE_SYSTEM_ZLIB=ON -DVTK_USE_SYSTEM_JSONCPP=ON -DVTK_USE_SYSTEM_NETCDF=OFF -DVTK_Group_Imaging=ON -DVTK_Group_MPI=OFF -DVTK_Group_Qt=ON -DVTK_Group_Tk=ON -DVTK_Group_Views=ON -DVTK_Group_Rendering=ON -DVTK_Group_StandAlone=ON -DVTK_Group_Web=OFF -DVTK_BUILD_ALL_MODULES=OFF -DVTK_MAKE_INSTANTIATORS=ON -DVTK_RENDERING_BACKEND:STRING=OpenGL _______________________________________________ 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 Sep 16 18:26:01 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 16 Sep 2015 18:26:01 -0400 Subject: [vtk-developers] OpenGL2 default Message-ID: <98328105e723f93733c9ac2abd2c3c12@mail.gmail.com> I just realized I never sent out an email about this. Yikes. Yesterday I committed a longstanding topic to change the VTK default to the OpenGL2 backend. While we have talked about this in general terms we never got down to specifics. A bunch of nightlies broke and I hope to work through that over the next day or two or chicken out and retreat :-) But...here is the gist, you can still set VTK_RENDERING_BACKEND to OpenGL or OpenGL2 as desired, existing settings will not change, we have only changed the default for cases where it has not been specified. We also have added a new setting named VTK_RENDERING_BACKEND_DEFAULT that lets applications set their preference (in their own CMakeLists file) for VTK while still allowing the user to override it with VTK_RENDERING_BACKEND. If you have any questions etc please let me know. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) 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 biddisco at cscs.ch Thu Sep 17 03:12:29 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Thu, 17 Sep 2015 07:12:29 +0000 Subject: [vtk-developers] Painters Message-ID: <50320452A334BD42A5EC72BAD21450993C81D1E6@MBX110.d.ethz.ch> Dear list, Did I read somewhere that with the switch to OpenGL2, the support for painters in VTK was being dropped? If this is the case, should I rewrite all my custom renderers as plain old mappers again - or is there some new approach that I should adopt. A link to any kind of wiki entry would be appreciated if one exists. thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Sep 17 09:36:25 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 17 Sep 2015 09:36:25 -0400 Subject: [vtk-developers] Painters In-Reply-To: <50320452A334BD42A5EC72BAD21450993C81D1E6@MBX110.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993C81D1E6@MBX110.d.ethz.ch> Message-ID: Hiya John, It depends on what the painters/mappers do. I think there are three main approaches you can use. The first would be to use the functions in vtkOpenGLPolydataMapper to modify the existing shader code generated by VTK to do something different (examples in Rendering/OpenGL2/Testing/Cxx/TestUserShader and TestUserShader2). You could do this by calling those functions in your application. The other approach is to subclass off of the mapper and modify the shader code there. vtkOpenGLPointGaussianMapper and vtkOpenGLSphereMapper are examples of this approach that provide a generic superclass (without the OpenGL) it can be quite a bit simpler if you are willing to just go with the OpenGL class. If you need to pass different data arrays to the shader then subclassing like that is the current way to go. The third option is to create a render pass that does something special to some or all of the props. This is more useful when your painters are being used to do some sort of rendering technique like shadow maps, or cell coloring, eye dome lighting etc. Examples of those include Rendeing/OpenGL2/*Pass* classes. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Biddiscombe, John A. *Sent:* Thursday, September 17, 2015 3:12 AM *To:* vtk-developers at vtk.org *Subject:* [vtk-developers] Painters Dear list, Did I read somewhere that with the switch to OpenGL2, the support for painters in VTK was being dropped? If this is the case, should I rewrite all my custom renderers as plain old mappers again - or is there some new approach that I should adopt. A link to any kind of wiki entry would be appreciated if one exists. thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coman.head at gmail.com Thu Sep 17 13:31:29 2015 From: coman.head at gmail.com (coman head) Date: Thu, 17 Sep 2015 19:31:29 +0200 Subject: [vtk-developers] VTK ImageMapper example show blank window Message-ID: Hi all, I am new to vtk. I posted a thread on pcl mailing list. http://www.pcl-users.org/PCLVisualizer-NOT-working-on-Ubuntu-14-04-td4039450.html In which, i got the problem is probably due to vtk. Then I compile vtk from source(i tried both 5.10 and 6.3) and build ImageMapper example with cmake and make. There is no compiling error thrown. But the result is still not right. I got the attached results. The correct result should be black background and a square filled with two colors. There is no other error or warning message. Please send an angle and help me!!!! many thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2015-09-17 18:13:43.png Type: image/png Size: 20835 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2015-09-17 19:20:08.png Type: image/png Size: 10600 bytes Desc: not available URL: From mathieu.westphal at kitware.com Fri Sep 18 04:05:26 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 18 Sep 2015 10:05:26 +0200 Subject: [vtk-developers] VTK ImageMapper example show blank window In-Reply-To: References: Message-ID: Hello Is this the example your are trying to run ?: http://www.vtk.org/Wiki/VTK/Examples/Cxx/Visualization/ImageMapper Which option have you enabled when compiling VTK, particularly which opengl ? This is probably a image buffer problem, you can try to use the methods: SetSwapBuffers(true/false) SetMultiSamples(0) Before calling Render(). Mathieu Westphal On Thu, Sep 17, 2015 at 7:31 PM, coman head wrote: > Hi all, > > I am new to vtk. I posted a thread on pcl mailing list. > http://www.pcl-users.org/PCLVisualizer-NOT-working-on-Ubuntu-14-04-td4039450.html In > which, i got the problem is probably due to vtk. > Then I compile vtk from source(i tried both 5.10 and 6.3) and build > ImageMapper example with cmake and make. There is no compiling error > thrown. But the result is still not right. > I got the attached results. The correct result should be black background > and a square filled with two colors. There is no other error or warning > message. Please send an angle and help me!!!! > > > many thanks, > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From molinarfamily2010 at gmail.com Fri Sep 18 11:27:29 2015 From: molinarfamily2010 at gmail.com (Alexander Molinar) Date: Fri, 18 Sep 2015 10:27:29 -0500 Subject: [vtk-developers] VTK 6.3 QT 5.3 Program Error after 6.3 Build cmake 3.1.0 Message-ID: I am new to VTK QT and am trying to abandon my TCL scripts for nice QT GUI. I used cmake 3.1.0 to build VTK 6.3 release. I enabled VTK_Group_Qt and have QT5.3 installed. I generated with cmake with the following QT settings. CMAKE_PREFIX_PATH = C:/Qt.5/5.3/msvc2013_64_opengl QT_QMAKE_EXECUTABLE = C:/Qt.5/5.3/msvc2013_64_opengl/bin/qmake.exe VTK_QT_VERSION = 5 It configures and generates with no errors. Then I used VS 2012 Professional to build the solutions build all then install with no errors. When I launch VTK.exe see below. Enter: "package require vtk" to load VTK commands % package require vtk couldn't load library "C:/VTK/bin/bin/Debug/vtkRenderingQtTCL-6.3.dll": this lib rary or a dependent library could not be found in library path attempt to provide package vtkRenderingQtTCL 6.3 failed: no version of package v tkRenderingQtTCL provided attempt to provide package vtkrenderingqt 6.3 failed: no version of package vtkr enderingqt provided attempt to provide package vtk 6.3 failed: no version of package vtk provided Any help would be greatly appreciated. AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Sep 22 09:44:12 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 22 Sep 2015 09:44:12 -0400 Subject: [vtk-developers] can't link to MPI libraries when building on Ubuntu 15.04, VTK6.3 In-Reply-To: <55F89A49.2040601@gmail.com> References: <55F6C199.1090208@gmail.com> <55F6EC75.4080304@gmail.com> <55F89A49.2040601@gmail.com> Message-ID: This merge request should fix this issue: https://gitlab.kitware.com/vtk/vtk/merge_requests/678 Utkarsh On Tue, Sep 15, 2015 at 6:23 PM, Chaffra Affouda wrote: > Thanks it does. > > > On 09/14/2015 04:34 PM, Utkarsh Ayachit wrote: >> >> Can you try if the attached patch addresses the issue? >> >> Thanks >> Utkarsh >> >> On Mon, Sep 14, 2015 at 3:21 PM, Chaffra J. Affouda >> wrote: >>> >>> Ok I did and it built. What hdf5/mpi variables do I need to update? >>> >>> Thanks, >>> Chaffra >>> >>> >>> On Mon, Sep 14, 2015, 14:19 Utkarsh Ayachit >>> wrote: >>>> >>>> For starters, turn off USE_SYSTEM_HDF5 and then confirm it builds. >>>> Once that's confirmed, you can turn the flag back on and then update >>>> the HDF5 library variables to include the MPI variables as well. >>>> >>>> On Mon, Sep 14, 2015 at 11:49 AM, Chaffra Affouda >>>> wrote: >>>>> >>>>> Utkarsh, >>>>> >>>>> Yes I am: >>>>> I built with -DUSE_SYSTEM_HDF5=ON. Should I be doing something else? >>>>> >>>>> Chaffra >>>>> >>>>> >>>>> On 09/14/2015 10:56 AM, Utkarsh Ayachit wrote: >>>>>> >>>>>> Chaffra, >>>>>> >>>>>> Are you by any change using system HDF5? >>>>>> >>>>>> Utkarsh >>>>>> >>>>>> On Mon, Sep 14, 2015 at 8:46 AM, Chaffra Affouda >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am getting a lot of undefined references when linking. I know it is >>>>>>> not >>>>>>> linking to MPI or the right MPI but I cannot see how. >>>>>>> I have openmpi installed and mpicc is pointing to the openmpi >>>>>>> version. >>>>>>> Can >>>>>>> any reproduce or help? Error is below >>>>>>> >>>>>>> Thanks, >>>>>>> Chaffra >>>>>>> >>>>>>> Linking CXX shared library ../../lib/libvtkIOAMR-6.3.so >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype >>>>>>> const&), >>>>>>> bool)': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb[_ZN3MPI2Op4InitEPFvPKvPviRKNS_8DatatypeEEb]+0x15): >>>>>>> undefined reference to `ompi_mpi_cxx_op_intercept' >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Intracomm::Create_graph(int, int const*, int const*, bool) >>>>>>> const': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm12Create_graphEiPKiS2_b[_ZNK3MPI9Intracomm12Create_graphEiPKiS2_b]+0x39): >>>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Graphcomm::Clone() const': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Graphcomm5CloneEv[_ZNK3MPI9Graphcomm5CloneEv]+0x35): >>>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Cartcomm::Clone() const': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI8Cartcomm5CloneEv[_ZNK3MPI8Cartcomm5CloneEv]+0x35): >>>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Intercomm::Merge(bool) const': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intercomm5MergeEb[_ZNK3MPI9Intercomm5MergeEb]+0x37): >>>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o: In >>>>>>> function >>>>>>> `MPI::Intracomm::Create(MPI::Group const&) const': >>>>>>> >>>>>>> >>>>>>> >>>>>>> vtkAMREnzoParticlesReader.cxx:(.text._ZNK3MPI9Intracomm6CreateERKNS_5GroupE[_ZNK3MPI9Intracomm6CreateERKNS_5GroupE]+0x3a): >>>>>>> undefined reference to `MPI::Comm::Comm()' >>>>>>> >>>>>>> >>>>>>> >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:vtkAMREnzoParticlesReader.cxx: >>>>>>> >>>>>>> (.text._ZNK3MPI9Intracomm5SplitEii[_ZNK3MPI9Intracomm5SplitEii]+0x36): >>>>>>> more >>>>>>> undefined references to `MPI::Comm::Comm()' follow >>>>>>> >>>>>>> >>>>>>> >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI8DatatypeE[_ZTVN3MPI8DatatypeE]+0x78): >>>>>>> undefined reference to ` MPI::Datatype::Free()' >>>>>>> >>>>>>> >>>>>>> >>>>>>> CMakeFiles/vtkIOAMR.dir/vtkAMREnzoParticlesReader.cxx.o:(.data.rel.ro._ZTVN3MPI3WinE[_ZTVN3MPI3WinE]+0x48): >>>>>>> undefined reference to `MPI::Win::Free()' >>>>>>> collect2: error: ld returned 1 exit status >>>>>>> IO/AMR/CMakeFiles/vtkIOAMR.dir/build.make:363: recipe for target >>>>>>> 'lib/libvtkIOAMR-6.3.so.1' failed >>>>>>> make[2]: *** [lib/libvtkIOAMR-6.3.so.1] Error 1 >>>>>>> CMakeFiles/Makefile2:6388: recipe for target >>>>>>> 'IO/AMR/CMakeFiles/vtkIOAMR.dir/all' failed >>>>>>> make[1]: *** [IO/AMR/CMakeFiles/vtkIOAMR.dir/all] Error 2 >>>>>>> Makefile:107: recipe for target 'all' failed >>>>>>> make: *** [all] Error 2 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 xabivtk at gmail.com Tue Sep 22 11:43:28 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Tue, 22 Sep 2015 17:43:28 +0200 Subject: [vtk-developers] Possible fix for vtkImageStencilData::InsertAndMergeExtent In-Reply-To: References: Message-ID: Hi David, here is a sample that reproduce the crash, plus another one found recently. both are related to the use of vtkImageStencilData::Subtract you can compile ImageStencil.cxx with CMakeLists.txt (providing VTK_DIR in Cmake gui) and the proposed fixes are in vtkImageStencilFixed-VTK6.h that you can activate by uncommenting the defines FIX1 & FIX2 at the beginning of the sample. some comments are included in the .h close to the code fix (look for #ifdef FIX). The first crash (FIX1 in vtkImageStencilData::InsertAndMergeExtent) only occurs with Mac because it is related to the access of a wrong memory location pointing to a value that is always negative on Windows, passing the " while(condition) " , whereas on Mac the value can be positive. This happens when the insertion must be at the beginning of the list. For that reason, it is not always reproductible even on Mac, but you should get it with less than 10 executions. The second one (FIX2 in vtkImageStencilData::RemoveExtent) is always reproductible in both Mac/Windows and is related to the bad ordering of some elements in a list that causes an infinite loop later in the execution. Both crashes appear randomly later in the code, not at the location of the fixes. Let me know if you want me to test other cases or need more information. 2015-07-30 19:18 GMT+02:00 David Gobbi : > Hi Xabi, > > It doesn't look like the right fix, I suspect that the flaw in the logic > is somewhere else in that method. Do you have any test code that I can use > to reproduce the bug? > > - David > > > On Thu, Jul 30, 2015 at 1:05 AM, Xabi Riobe wrote: > >> Hi, >> >> I'm in the process of migrating from 5.10.1 to 6.3 and have found a fix i >> had in vtkImageStencilData::InsertAndMergeExtent from one year ago. >> >> at the end of the method there is this loop: >> >> while (r1 < clist[insertIndex-1]) >> { >> clist[insertIndex] = clist[insertIndex-2]; >> clist[insertIndex+1] = clist[insertIndex-1]; >> insertIndex -= 2; >> } >> >> and i have this line added : if (insertIndex <= 1) break; >> with the comment: "avoid accessing out of range elements, which produces >> incorrect stencil that causes a random crash later when used in >> vtkImageStencilExecute" >> >> This random crash occured on Mac, never reproduced on Windows. >> >> I was wondering if by looking at the code you think it's a correct fix >> that can be merged. >> >> Thanks >> >> Xabi. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8) PROJECT(ImageStencil) find_package(VTK REQUIRED) include(${VTK_USE_FILE}) add_executable(ImageStencil MACOSX_BUNDLE ImageStencil) if(VTK_LIBRARIES) target_link_libraries(ImageStencil ${VTK_LIBRARIES}) else() target_link_libraries(ImageStencil vtkHybrid vtkWidgets) endif() -------------- next part -------------- #include #include #include #include #include #include #include #include #include #include #include #include #include //#define FIX1 // Uncomment to fix bug 1 //#define FIX2 // Uncomment to fix bug 2 #if defined(FIX1) || defined(FIX2) #include "vtkImageStencilFixed-VTK6.h" #define vtkImageStencilData vtkImageStencilDataFixed #endif static void CreateColorImage(vtkImageData*, unsigned int channel); static void CreateMask(vtkImageData*, int, int, int, int, int, int); int main(int, char *[]) { vtkSmartPointer image1 = vtkSmartPointer::New(); CreateColorImage(image1, 0); // Create a red image vtkSmartPointer mask = vtkSmartPointer::New(); CreateMask(mask, 10, 10, 10, 3, 3, 3); vtkSmartPointer stencilData = vtkSmartPointer::New(); vtkSmartPointer imageToImageStencil = vtkSmartPointer::New(); imageToImageStencil->SetInputData(mask); imageToImageStencil->ThresholdByUpper(122); imageToImageStencil->Update(); stencilData->Add(imageToImageStencil->GetOutput()); { vtkSmartPointer mask = vtkSmartPointer::New(); CreateMask(mask, 6, 6, 6, 2, 2, 2); vtkSmartPointer imageToImageStencil = vtkSmartPointer::New(); imageToImageStencil->SetInputData(mask); imageToImageStencil->ThresholdByUpper(122); imageToImageStencil->Update(); stencilData->Add(imageToImageStencil->GetOutput()); } { vtkSmartPointer mask = vtkSmartPointer::New(); CreateMask(mask, 7, 7, 7, 1, 1, 1); vtkSmartPointer imageToImageStencil = vtkSmartPointer::New(); imageToImageStencil->SetInputData(mask); imageToImageStencil->ThresholdByUpper(122); imageToImageStencil->Update(); stencilData->Subtract(imageToImageStencil->GetOutput()); } vtkSmartPointer stencil = vtkSmartPointer::New(); stencil->SetStencilData(stencilData); stencil->ReverseStencilOn(); stencil->SetBackgroundValue(0.0); stencil->SetInputData(image1); stencil->Update(); // Create an actor vtkSmartPointer actor = vtkSmartPointer::New(); actor->GetMapper()->SetInputConnection(stencil->GetOutputPort()); // Setup renderer vtkSmartPointer renderer = vtkSmartPointer::New(); renderer->AddActor(actor); renderer->ResetCamera(); // Setup render window vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); // Setup render window interactor vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); // Render and start interaction renderWindowInteractor->SetRenderWindow(renderWindow); renderWindow->Render(); #ifdef __APPLE__ renderWindow->SetPosition(50, 50); #endif renderWindowInteractor->Start(); return EXIT_SUCCESS; } void CreateColorImage(vtkImageData* image, const unsigned int channel) { unsigned int dim = 20; image->SetDimensions(dim, dim, dim); image->AllocateScalars(VTK_UNSIGNED_CHAR,3); for(unsigned int x = 0; x < dim; x++) { for(unsigned int y = 0; y < dim; y++) { for(unsigned int z = 0; z < dim; z++) { unsigned char* pixel = static_cast(image->GetScalarPointer(x,y,z)); pixel[0] = 0; pixel[1] = 0; pixel[2] = 0; pixel[channel] = 255; } } } image->Modified(); } static void CreateMask(vtkImageData* image, int px, int py, int pz, int w, int h, int d) { unsigned int dim = 20; image->SetDimensions(dim, dim, dim); image->AllocateScalars(VTK_UNSIGNED_CHAR, 1); for(unsigned int x = 0; x < dim; x++) { for(unsigned int y = 0; y < dim; y++) { for(unsigned int z = 0; z < dim; z++) { unsigned char* pixel = static_cast(image->GetScalarPointer(x,y,z)); //if(x < px - w || x > px + w || y < py - h || y > py + h || z < pz - d || z > pz + d) if(abs(int(x) - px) + abs(int(y) - py) + abs(int(z) - pz) > int(w + h + z)) { pixel[0] = 0; } else { pixel[0] = 255; } } } } image->Modified(); } -------------- next part -------------- A non-text attachment was scrubbed... Name: vtkImageStencilFixed-VTK6.h Type: text/x-chdr Size: 14794 bytes Desc: not available URL: From david.gobbi at gmail.com Tue Sep 22 14:02:20 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 22 Sep 2015 12:02:20 -0600 Subject: [vtk-developers] Possible fix for vtkImageStencilData::InsertAndMergeExtent In-Reply-To: References: Message-ID: Hi Xabi, Thanks, these will be very useful. Cheers, - David On Tue, Sep 22, 2015 at 9:43 AM, Xabi Riobe wrote: > Hi David, > > here is a sample that reproduce the crash, plus another one found recently. > both are related to the use of vtkImageStencilData::Subtract > > you can compile ImageStencil.cxx with CMakeLists.txt (providing VTK_DIR in > Cmake gui) and the proposed fixes are in vtkImageStencilFixed-VTK6.h that > you can activate by uncommenting the defines FIX1 & FIX2 at the beginning > of the sample. > > some comments are included in the .h close to the code fix (look for > #ifdef FIX). > > The first crash (FIX1 in vtkImageStencilData::InsertAndMergeExtent) only > occurs with Mac because it is related to the access of a wrong memory > location pointing to a value that is always negative on Windows, passing > the " while(condition) " , whereas on Mac the value can be positive. This > happens when the insertion must be at the beginning of the list. > For that reason, it is not always reproductible even on Mac, but you > should get it with less than 10 executions. > > The second one (FIX2 in vtkImageStencilData::RemoveExtent) is always > reproductible in both Mac/Windows and is related to the bad ordering of > some elements in a list that causes an infinite loop later in the execution. > > Both crashes appear randomly later in the code, not at the location of the > fixes. > > Let me know if you want me to test other cases or need more information. > > > 2015-07-30 19:18 GMT+02:00 David Gobbi : > >> Hi Xabi, >> >> It doesn't look like the right fix, I suspect that the flaw in the logic >> is somewhere else in that method. Do you have any test code that I can use >> to reproduce the bug? >> >> - David >> >> >> On Thu, Jul 30, 2015 at 1:05 AM, Xabi Riobe wrote: >> >>> Hi, >>> >>> I'm in the process of migrating from 5.10.1 to 6.3 and have found a fix >>> i had in vtkImageStencilData::InsertAndMergeExtent from one year ago. >>> >>> at the end of the method there is this loop: >>> >>> while (r1 < clist[insertIndex-1]) >>> { >>> clist[insertIndex] = clist[insertIndex-2]; >>> clist[insertIndex+1] = clist[insertIndex-1]; >>> insertIndex -= 2; >>> } >>> >>> and i have this line added : if (insertIndex <= 1) break; >>> with the comment: "avoid accessing out of range elements, which produces >>> incorrect stencil that causes a random crash later when used in >>> vtkImageStencilExecute" >>> >>> This random crash occured on Mac, never reproduced on Windows. >>> >>> I was wondering if by looking at the code you think it's a correct fix >>> that can be merged. >>> >>> Thanks >>> >>> Xabi. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 22 19:18:03 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 22 Sep 2015 17:18:03 -0600 Subject: [vtk-developers] New WRAP_EXCLUDE_PYTHON Message-ID: Hi All, I've just merged a patch that adds a new file property to VTK: WRAP_EXCLUDE_PYTHON causes the python wrappers to ignore a file. >From now on, WRAP_EXCLUDE is only used for Tcl and Java. The python wrappers will try to wrap anything not marked WRAP_EXCLUDE_PYTHON. The goal is to make more VTK classes available from the python wrappers. The often-misunderstood WRAP_SPECIAL file property, which was used to define a whitelist for python wrapping, has been retired (2010-2015, RIP). Perhaps one day these WRAP_EXCLUDE - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 23 08:41:57 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 23 Sep 2015 06:41:57 -0600 Subject: [vtk-developers] New WRAP_EXCLUDE_PYTHON In-Reply-To: References: Message-ID: The wrapping has identified a few classes that break the "rule of three": https://open.cdash.org/viewBuildError.php?type=1&buildid=4025415 I'll see if I can fix these, but I might need to seek advice on some of them. - David On Tue, Sep 22, 2015 at 5:18 PM, David Gobbi wrote: > Hi All, > > I've just merged a patch that adds a new file property to VTK: > > WRAP_EXCLUDE_PYTHON causes the python wrappers to ignore a file. > > From now on, WRAP_EXCLUDE is only used for Tcl and Java. The python > wrappers will try to wrap anything not marked WRAP_EXCLUDE_PYTHON. > The goal is to make more VTK classes available from the python wrappers. > > The often-misunderstood WRAP_SPECIAL file property, which was used to > define a whitelist for python wrapping, has been retired (2010-2015, RIP). > > Perhaps one day these WRAP_EXCLUDE > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Sep 23 10:00:02 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 23 Sep 2015 10:00:02 -0400 Subject: [vtk-developers] New WRAP_EXCLUDE_PYTHON In-Reply-To: References: Message-ID: On Wed, Sep 23, 2015 at 8:41 AM, David Gobbi wrote: > The wrapping has identified a few classes that break the "rule of three": > https://open.cdash.org/viewBuildError.php?type=1&buildid=4025415 > > I'll see if I can fix these, but I might need to seek advice on some of > them. > vtkFreeTypeToolsCleanup is the one I'm familiar with, and it can just have an empty copy constructor as it's stateless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 23 12:28:42 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 23 Sep 2015 10:28:42 -0600 Subject: [vtk-developers] New WRAP_EXCLUDE_PYTHON In-Reply-To: References: Message-ID: On Wed, Sep 23, 2015 at 8:00 AM, David Lonie wrote: > On Wed, Sep 23, 2015 at 8:41 AM, David Gobbi > wrote: > >> The wrapping has identified a few classes that break the "rule of three": >> https://open.cdash.org/viewBuildError.php?type=1&buildid=4025415 >> >> I'll see if I can fix these, but I might need to seek advice on some of >> them. >> > > vtkFreeTypeToolsCleanup is the one I'm familiar with, and it can just have > an empty copy constructor as it's stateless. > It has a public constructor, so it can potentially have multiple instances. I added a counter to make sure it doesn't call SetInstance(NULL) until all instances have destructed. https://gitlab.kitware.com/vtk/vtk/merge_requests/686 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From xabivtk at gmail.com Thu Sep 24 05:29:24 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Thu, 24 Sep 2015 11:29:24 +0200 Subject: [vtk-developers] Picking problem with OpenGL2 and DepthPeeling Message-ID: Hi, I try to pick in a scene that contains a translucent object and the pick fails if I use the OpenGL2 backend (v6.3.0), tested on VS2013 32 bits with nVidia Quadro 4000 (driver 353.30) The same code works with OpenGL backend. I can reproduce it with the sample code attached, based on the example at http://www.vtk.org/Wiki/VTK/Examples/Cxx/Interaction/Picking with these lines added: renderer->SetUseDepthPeeling(1); renderer->SetMaximumNumberOfPeels(8); renderWindow->SetAlphaBitPlanes(1); renderWindow->SetMultiSamples(0); and the opacity set to 0.5 for the plane. If i don't use depth peeling, or if the plane is opaque, the picker works as expected. It seems that the pick fails when in vtkOpenGLRenderer::DonePick the float value returned by GetZbufferData is 1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include // Handle mouse events class MouseInteractorStyle2 : public vtkInteractorStyleTrackballCamera { public: static MouseInteractorStyle2* New(); vtkTypeMacro(MouseInteractorStyle2, vtkInteractorStyleTrackballCamera); virtual void OnLeftButtonDown() { int* clickPos = this->GetInteractor()->GetEventPosition(); // Pick from this location. vtkSmartPointer picker = vtkSmartPointer::New(); picker->Pick(clickPos[0], clickPos[1], 0, this->GetDefaultRenderer()); double* pos = picker->GetPickPosition(); std::cout << "Pick position (world coordinates) is: " << pos[0] << " " << pos[1] << " " << pos[2] << std::endl; std::cout << "Picked actor: " << picker->GetActor() << std::endl; //Create a sphere vtkSmartPointer sphereSource = vtkSmartPointer::New(); sphereSource->SetCenter(pos[0], pos[1], pos[2]); sphereSource->SetRadius(0.1); //Create a mapper and actor vtkSmartPointer mapper = vtkSmartPointer::New(); mapper->SetInputConnection(sphereSource->GetOutputPort()); vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); //this->GetInteractor()->GetRenderWindow()->GetRenderers()->GetDefaultRenderer()->AddActor(actor); this->GetDefaultRenderer()->AddActor(actor); // Forward events vtkInteractorStyleTrackballCamera::OnLeftButtonDown(); } private: }; vtkStandardNewMacro(MouseInteractorStyle2); int main(int, char *[]) { vtkSmartPointer planeSource = vtkSmartPointer::New(); planeSource->Update(); // Create a polydata object vtkPolyData* polydata = planeSource->GetOutput(); // Create a mapper vtkSmartPointer mapper = vtkSmartPointer::New(); #if VTK_MAJOR_VERSION <= 5 mapper->SetInput(polydata); #else mapper->SetInputData(polydata); #endif // Create an actor vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); //actor->GetProperty()->SetOpacity(0.5); std::cout << "Actor address: " << actor << std::endl; // A renderer and render window vtkSmartPointer renderer = vtkSmartPointer::New(); vtkSmartPointer renderWindow = vtkSmartPointer::New(); renderWindow->AddRenderer(renderer); //////////////////////////////////////// // BUG : no picking !!! //////////////////////////////////////// renderer->SetUseDepthPeeling(1); renderer->SetMaximumNumberOfPeels(8); renderWindow->SetAlphaBitPlanes(1); renderWindow->SetMultiSamples(0); //////////////////////////////////////// // An interactor vtkSmartPointer renderWindowInteractor = vtkSmartPointer::New(); renderWindowInteractor->SetRenderWindow(renderWindow); // Set the custom stype to use for interaction. vtkSmartPointer style = vtkSmartPointer::New(); style->SetDefaultRenderer(renderer); renderWindowInteractor->SetInteractorStyle(style); // Add the actors to the scene renderer->AddActor(actor); renderer->SetBackground(0, 0, 1); // Render and interact renderWindow->Render(); renderWindowInteractor->Initialize(); renderWindowInteractor->Start(); return EXIT_SUCCESS; } From anatol.pomozov at gmail.com Thu Sep 24 09:18:13 2015 From: anatol.pomozov at gmail.com (Anatol Pomozov) Date: Thu, 24 Sep 2015 21:18:13 +0800 Subject: [vtk-developers] VTK fails to compile with gdal2.0 Message-ID: I am trying to compile VTK with gdal 2.0 and got this compilation error: [ 25%] Building CXX object Wrapping/Python/CMakeFiles/vtkCommonDataModelPythonD.dir/vtkPointSetPython.cxx.o /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx: In constructor 'vtkGDALVectorReader::Internal::Internal(const char*, int, int, int)': /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx:47:20: error: 'Open' is not a member of 'OGRSFDriverRegistrar' this->Source = OGRSFDriverRegistrar::Open( srcName, srcMode, &this->Driver ); ^ /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx: In destructor 'vtkGDALVectorReader::Internal::~Internal()': /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx:64:22: warning: 'static void OGRDataSource::DestroyDataSource(OGRDataSource*)' is deprecated [-Wdeprecated-declarations] OGRDataSource::DestroyDataSource( this->Source ); ^ In file included from /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx:32:0: /usr/include/ogrsf_frmts.h:245:25: note: declared here static void DestroyDataSource( OGRDataSource * ) OGR_DEPRECATED("Use GDALDataset class instead"); ^ /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx:64:54: warning: 'static void OGRDataSource::DestroyDataSource(OGRDataSource*)' is deprecated [-Wdeprecated-declarations] OGRDataSource::DestroyDataSource( this->Source ); ^ In file included from /build/vtk/src/VTK-6.1.0/IO/GDAL/vtkGDALVectorReader.cxx:32:0: /usr/include/ogrsf_frmts.h:245:25: note: declared here static void DestroyDataSource( OGRDataSource * ) OGR_DEPRECATED("Use GDALDataset class instead"); ^ IO/GDAL/CMakeFiles/vtkIOGDAL.dir/build.make:72: recipe for target 'IO/GDAL/CMakeFiles/vtkIOGDAL.dir/vtkGDALVectorReader.cxx.o' failed make[2]: *** [IO/GDAL/CMakeFiles/vtkIOGDAL.dir/vtkGDALVectorReader.cxx.o] Error 1 CMakeFiles/Makefile2:27630: recipe for target 'IO/GDAL/CMakeFiles/vtkIOGDAL.dir/all' failed make[1]: *** [IO/GDAL/CMakeFiles/vtkIOGDAL.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... gdal 2.0 changed some API. Here is the list - http://svn.osgeo.org/gdal/trunk/gdal/MIGRATION_GUIDE.TXT From ken.martin at kitware.com Thu Sep 24 10:37:29 2015 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 24 Sep 2015 10:37:29 -0400 Subject: [vtk-developers] Picking problem with OpenGL2 and DepthPeeling In-Reply-To: References: Message-ID: <4a86e1519564c55cffeef2e29171a650@mail.gmail.com> Thanks! I believe the new depth peeling code is probably leaving the zbuffer in a different state than the opaque z buffer. If you get a second could you try the attached patch and see if it works for you. It is based on a more recent VTK but it is a tiny patch. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Xabi Riobe *Sent:* Thursday, September 24, 2015 5:29 AM *To:* VTK Developers *Subject:* [vtk-developers] Picking problem with OpenGL2 and DepthPeeling Hi, I try to pick in a scene that contains a translucent object and the pick fails if I use the OpenGL2 backend (v6.3.0), tested on VS2013 32 bits with nVidia Quadro 4000 (driver 353.30) The same code works with OpenGL backend. I can reproduce it with the sample code attached, based on the example at http://www.vtk.org/Wiki/VTK/Examples/Cxx/Interaction/Picking with these lines added: renderer->SetUseDepthPeeling(1); renderer->SetMaximumNumberOfPeels(8); renderWindow->SetAlphaBitPlanes(1); renderWindow->SetMultiSamples(0); and the opacity set to 0.5 for the plane. If i don't use depth peeling, or if the plane is opaque, the picker works as expected. It seems that the pick fails when in vtkOpenGLRenderer::DonePick the float value returned by GetZbufferData is 1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DPPick.patch Type: application/octet-stream Size: 1503 bytes Desc: not available URL: From ben.boeckel at kitware.com Thu Sep 24 17:15:51 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 24 Sep 2015 17:15:51 -0400 Subject: [vtk-developers] [ANN] Gitlab expected downtime today for 8.0 upgrade Message-ID: <20150924211551.GA4010@megas.khq.kitware.com> Hi, Gitlab (and buildbot) will be down for about 20 minutes to an hour starting around 5:30 while we upgrade to 8.0. New features with 8.0 include: - new UI design; - separate tabs for "closed" and "merged" MRs; - all of our existing patches merged (though we need another for some bits new features missed); - better performance (apparently gitlab used to keep 2 clones per repo; now it is only one); - added refs for merge requests as refs/merge-requests/:id from the target repository; and - ability to upload files to issues and merge requests. We will be working to enable another feature, reply-by-email where you can add a Gitlab comment by replying to any notification email. Also, LWN has an article about it in this week's edition: http://lwn.net/SubscriberLink/658072/2104b1cf923815e4/ Thanks, --Ben From ben.boeckel at kitware.com Thu Sep 24 18:06:18 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 24 Sep 2015 18:06:18 -0400 Subject: [vtk-developers] [ANN] Gitlab expected downtime today for 8.0 upgrade In-Reply-To: <20150924211551.GA4010@megas.khq.kitware.com> References: <20150924211551.GA4010@megas.khq.kitware.com> Message-ID: <20150924220618.GG6565@megas.khq.kitware.com> On Thu, Sep 24, 2015 at 17:15:51 -0400, Ben Boeckel wrote: > Gitlab (and buildbot) will be down for about 20 minutes to an hour starting > around 5:30 while we upgrade to 8.0. Gitlab is now back online! --Ben From xabivtk at gmail.com Fri Sep 25 07:49:46 2015 From: xabivtk at gmail.com (Xabi Riobe) Date: Fri, 25 Sep 2015 13:49:46 +0200 Subject: [vtk-developers] Fwd: Picking problem with OpenGL2 and DepthPeeling In-Reply-To: References: <4a86e1519564c55cffeef2e29171a650@mail.gmail.com> Message-ID: Hi Ken, with the patch we can pick the transparent surfaces but not the opaque ones anymore. for example in the sample you can pick on the plane but not on the spheres that are created. 2015-09-24 16:37 GMT+02:00 Ken Martin : > Thanks! I believe the new depth peeling code is probably leaving the > zbuffer in a different state than the opaque z buffer. If you get a second > could you try the attached patch and see if it works for you. It is based > on a more recent VTK but it is a tiny patch. > > > > Thanks > > Ken > > > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > ken.martin at kitware.com > > 919 869-8871 (w) > > > > > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Xabi Riobe > *Sent:* Thursday, September 24, 2015 5:29 AM > *To:* VTK Developers > *Subject:* [vtk-developers] Picking problem with OpenGL2 and DepthPeeling > > > > Hi, > > > > I try to pick in a scene that contains a translucent object and the pick > fails if I use the OpenGL2 backend (v6.3.0), tested on VS2013 32 bits with > nVidia Quadro 4000 (driver 353.30) > > > > The same code works with OpenGL backend. > > > > I can reproduce it with the sample code attached, based on the example at > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Interaction/Picking with these > lines added: > > > > renderer->SetUseDepthPeeling(1); > > renderer->SetMaximumNumberOfPeels(8); > > renderWindow->SetAlphaBitPlanes(1); > > renderWindow->SetMultiSamples(0); > > > > and the opacity set to 0.5 for the plane. > > > > If i don't use depth peeling, or if the plane is opaque, the picker works > as expected. > > > > It seems that the pick fails when in vtkOpenGLRenderer::DonePick the float > value returned by GetZbufferData is 1.0 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 25 14:03:28 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 25 Sep 2015 12:03:28 -0600 Subject: [vtk-developers] PGI compiler dashboard error Message-ID: The agora pgi dashboard has been reporting a compiler error recently, perhaps a bug in its SDK? Common/System/vtkDirectory.cxx", line 170: error: a value of type "dirent *" cannot be assigned to an entity of type "dirent64 *" for (d = readdir(dir); d; d = readdir(dir)) https://open.cdash.org/viewBuildError.php?buildid=4030939 - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Sep 25 14:38:05 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 25 Sep 2015 14:38:05 -0400 Subject: [vtk-developers] PGI compiler dashboard error In-Reply-To: References: Message-ID: <20150925183805.GA22045@megas.khq.kitware.com> On Fri, Sep 25, 2015 at 12:03:28 -0600, David Gobbi wrote: > The agora pgi dashboard has been reporting a compiler error recently, > perhaps a bug in its SDK? > > Common/System/vtkDirectory.cxx", line 170: error: > a value of type "dirent *" cannot be assigned to an entity of type > "dirent64 *" > for (d = readdir(dir); d; d = readdir(dir)) > > https://open.cdash.org/viewBuildError.php?buildid=4030939 Yeah, it's on my list. kwsys has a fix for this issue, but I haven't translated it into what vtk is doing yet. --Ben From ben.boeckel at kitware.com Mon Sep 28 11:22:36 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 28 Sep 2015 11:22:36 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! Message-ID: <20150928152236.GA11816@megas.khq.kitware.com> Hi, As I see some people have noticed, buildbot can now be driven by `Do: test` which triggers ~immediately rather than on a 10 minute schedule. With this come some other nifty bits :) . You may also have noticed buildbot now comments back to your MR when it is complete :) . If anyone sees duplicate messages where the first does not involve "slave lost? will retry in the future" somewhere in the list, please comment while mentioning @buildbot. First, some important information: If you are currently using `@buildbot test`, if `Do: test` is found, any `@buildbot test` mechanism is ignored, so moving to `Do: test` will not cause duplicate builds. A transistion of a few weeks should suffice before we turn off `@buildbot test`. It also needs to be at the bottom of your comment, the same as other kwrobot commands. It is currently only on VTK for now; I'll announce to the other projects when it has been enabled for them (kwrobot will tell you if it is not ready as well); you will probably then need to edit your comment to remove `Do: test` so `@buildbot test` doesn't skip it though. And now for the fun bits: With the new `Do: test` command, buildbot keeps a list of active commands for a merge request. For example, this may be used to build only on Python3 builders: Do: test --regex-include \+python3 to *add* MPI builders to the set, give this command: Do: test --regex-include \+mpi When these two commands are active, any builder with +python3 or +mpi in its name will be built for updates to the MR. If, however, you now only need MPI builders, this command: Do: test --clear --regex-include \+mpi will empty out the command list before adding the command for +mpi. To test any Python except on Windows with MPI: Do: test --regex-include \+python --regex-exclude -windows.*\+mpi On any branch update, all active commands will be used, but --oneshot may be used to not remember the command. The breakdown for build names is as follows: project-host-os-libtype-buildtype+feature1+feature2 * project: always "vtk" for vtk * host: the buildbot host * os: one of "windows", "osx", or "linux" * libtype: "shared" or "static" * buildtype: "release" or "debug" And a grouped list of features (not exhaustive): * python * python3 * tcl * java * opengl2 (OpenGL1 if not there; will be flipped to be +opengl1 at some point) * mpi * qt * qt5 * clang * gcc (this is not used everywhere yet: if not specified and not Windows, it's probably gcc; this will be fixed when we rename builders to turn +opengl2 -> +opengl1) * vs (Visual Studio generator; all Windows builders are MSVC) * icc * pgi * tbb * openmp All features in a build name are in alphabetical order, so matching a collection of features shouldn't need too many regex hacks. Some nitty-gritty details should the need arise: Arguments may not contain spaces (there should be no reason to) and there is no escaping other than Python's regex nor quoting (i.e., the command is split on spaces and that's it). Extra spaces between arguments shouldn't be a problem. The command is applied in whitelist -> blacklist order, so --regex-exclude will never be overridden within each command; however, each command is considered separately and then union'd with the other command results (so that you can include builders later and not have to hunt down the command excluding it from before). Any errors in argument parsing renders the entire command as ignored. The full list of arguments: * --oneshot only build the *current* hash of the branch; updates will not be built using this command * --stop clear the list of commands for the merge request * --superbuild build the superbuilds related to the project (vtk-superbuild is currently excluded from this since it is only a nightly test) * --clear: clear previous commands and add this command to the list * --regex-include only build on builders matching (a Python regex) * --regex-exclude excludes builds on builders matching (a Python regex) --Ben From dan.lipsa at kitware.com Mon Sep 28 18:08:02 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Mon, 28 Sep 2015 18:08:02 -0400 Subject: [vtk-developers] Parallel LIC python wrapping failure Message-ID: Hi David and all, We get the following build error on VTK master which seems related to the python wrapping https://open.cdash.org/viewBuildError.php?buildid=4034719 to get this, you'll need to enable python and vtkRenderingParallelLIC. I think the vtkRenderingParallelLICPythonD library just needs mpi and mpi_cxx libraries but I am not sure how to pass them to the wrapping code. vtkRenderingParallelLIC link privately with this libraries so this is no help to vtkRenderingParallelLICPythonD. Thanks, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 29 08:43:48 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 29 Sep 2015 06:43:48 -0600 Subject: [vtk-developers] Parallel LIC python wrapping failure In-Reply-To: References: Message-ID: Hi Dan, I've put together a wrap-exclude-python patch, but I suspect that it won't fix the issue: https://gitlab.kitware.com/vtk/vtk/merge_requests/709 It's possible that vtk_mpi_link(${vtk-module}PythonD) would do what's needed, but it's strange that the other parallel modules build fine without explicitly linking the wrappers to MPI. - David On Mon, Sep 28, 2015 at 4:08 PM, Dan Lipsa wrote: > Hi David and all, > We get the following build error on VTK master which seems related to the > python wrapping > > https://open.cdash.org/viewBuildError.php?buildid=4034719 > > > to get this, you'll need to enable python and vtkRenderingParallelLIC. > > I think the vtkRenderingParallelLICPythonD library just needs mpi and > mpi_cxx libraries but I am not sure how to pass them to the wrapping code. > > vtkRenderingParallelLIC link privately with this libraries so this is no > help to vtkRenderingParallelLICPythonD. > > > Thanks, > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Sep 29 09:56:56 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 29 Sep 2015 09:56:56 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! In-Reply-To: <20150928152236.GA11816@megas.khq.kitware.com> References: <20150928152236.GA11816@megas.khq.kitware.com> Message-ID: <4433E981-69A4-4F59-B165-9FA74411D299@kitware.com> Hi Ben, > ... buildbot can now be driven by `Do: test` which triggers ~immediately... Awesome! > ... > The command is applied in whitelist -> blacklist order, so > --regex-exclude will never be overridden within each command; however, > each command is considered separately and then union'd with the other > command results (so that you can include builders later and not have to > hunt down the command excluding it from before). Does this mean: Do: test --regex-include \+python --regex-exclude -windows.*\+mpi Do: test --regex-include \+tbb --regex-exclude -pgi would cause one set of tests to run that included python (except on windows) and tbb (except on PGI compilers)? Can multiple "Do: test" statements be in the same comment? If multiple comments are required, and since tests are queued "~immediately", will this cause test reruns? Just curious. Thanks, David From utkarsh.ayachit at kitware.com Tue Sep 29 10:25:17 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 29 Sep 2015 10:25:17 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! In-Reply-To: <20150928152236.GA11816@megas.khq.kitware.com> References: <20150928152236.GA11816@megas.khq.kitware.com> Message-ID: Can these be documented in the VTK/ParaView contributing guide please? Thanks. On Mon, Sep 28, 2015 at 11:22 AM, Ben Boeckel wrote: > Hi, > > As I see some people have noticed, buildbot can now be driven by `Do: > test` which triggers ~immediately rather than on a 10 minute schedule. > With this come some other nifty bits :) . > > You may also have noticed buildbot now comments back to your MR when it > is complete :) . If anyone sees duplicate messages where the first does > not involve "slave lost? will retry in the future" somewhere in the > list, please comment while mentioning @buildbot. > > First, some important information: > > If you are currently using `@buildbot test`, if `Do: test` is found, any > `@buildbot test` mechanism is ignored, so moving to `Do: test` will not > cause duplicate builds. A transistion of a few weeks should suffice > before we turn off `@buildbot test`. It also needs to be at the bottom > of your comment, the same as other kwrobot commands. > > It is currently only on VTK for now; I'll announce to the other projects > when it has been enabled for them (kwrobot will tell you if it is not > ready as well); you will probably then need to edit your comment to > remove `Do: test` so `@buildbot test` doesn't skip it though. > > And now for the fun bits: > > With the new `Do: test` command, buildbot keeps a list of active > commands for a merge request. For example, this may be used to build > only on Python3 builders: > > Do: test --regex-include \+python3 > > to *add* MPI builders to the set, give this command: > > Do: test --regex-include \+mpi > > When these two commands are active, any builder with +python3 or +mpi in > its name will be built for updates to the MR. If, however, you now only > need MPI builders, this command: > > Do: test --clear --regex-include \+mpi > > will empty out the command list before adding the command for +mpi. > > To test any Python except on Windows with MPI: > > Do: test --regex-include \+python --regex-exclude -windows.*\+mpi > > On any branch update, all active commands will be used, but --oneshot > may be used to not remember the command. > > The breakdown for build names is as follows: > > project-host-os-libtype-buildtype+feature1+feature2 > > * project: always "vtk" for vtk > * host: the buildbot host > * os: one of "windows", "osx", or "linux" > * libtype: "shared" or "static" > * buildtype: "release" or "debug" > > And a grouped list of features (not exhaustive): > > * python > * python3 > * tcl > * java > > * opengl2 (OpenGL1 if not there; will be flipped to be +opengl1 at > some point) > > * mpi > * qt > * qt5 > > * clang > * gcc (this is not used everywhere yet: if not specified and not > Windows, it's probably gcc; this will be fixed when we rename > builders to turn +opengl2 -> +opengl1) > * vs (Visual Studio generator; all Windows builders are MSVC) > * icc > * pgi > > * tbb > * openmp > > All features in a build name are in alphabetical order, so matching a > collection of features shouldn't need too many regex hacks. > > Some nitty-gritty details should the need arise: > > Arguments may not contain spaces (there should be no reason to) and > there is no escaping other than Python's regex nor quoting (i.e., the > command is split on spaces and that's it). Extra spaces between > arguments shouldn't be a problem. > > The command is applied in whitelist -> blacklist order, so > --regex-exclude will never be overridden within each command; however, > each command is considered separately and then union'd with the other > command results (so that you can include builders later and not have to > hunt down the command excluding it from before). > > Any errors in argument parsing renders the entire command as ignored. > > The full list of arguments: > > * --oneshot > only build the *current* hash of the branch; updates will not be > built using this command > * --stop > clear the list of commands for the merge request > * --superbuild > build the superbuilds related to the project (vtk-superbuild is > currently excluded from this since it is only a nightly test) > * --clear: > clear previous commands and add this command to the list > * --regex-include > only build on builders matching (a Python regex) > * --regex-exclude > excludes builds on builders matching (a Python regex) > > --Ben > _______________________________________________ > 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 ben.boeckel at kitware.com Tue Sep 29 11:05:09 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 29 Sep 2015 11:05:09 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! In-Reply-To: <4433E981-69A4-4F59-B165-9FA74411D299@kitware.com> References: <20150928152236.GA11816@megas.khq.kitware.com> <4433E981-69A4-4F59-B165-9FA74411D299@kitware.com> Message-ID: <20150929150509.GA5829@megas.khq.kitware.com> On Tue, Sep 29, 2015 at 09:56:56 -0400, David Thompson wrote: > > The command is applied in whitelist -> blacklist order, so > > --regex-exclude will never be overridden within each command; however, > > each command is considered separately and then union'd with the other > > command results (so that you can include builders later and not have to > > hunt down the command excluding it from before). > > Does this mean: > > Do: test --regex-include \+python --regex-exclude -windows.*\+mpi > Do: test --regex-include \+tbb --regex-exclude -pgi Should be \+pgi. > would cause one set of tests to run that included python (except on > windows) and tbb (except on PGI compilers)? Can multiple "Do: test" > statements be in the same comment? If multiple comments are required, > and since tests are queued "~immediately", will this cause test > reruns? Just curious. Ooh, interesting. They shouldn't double build. The logic for this would make 2 comments that tests have been scheduled (but only 1 kwrobot comment per comment with >1 Do: test), but buildbot itself should merge the two into one column and not double build (columns are based on "source stamps" which would be the same for a given MR update). You may get 2 report comments at first. Merge updates would process both commands at once and wouldn't have this weirdness. Thanks, --Ben From david.gobbi at gmail.com Tue Sep 29 11:05:53 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 29 Sep 2015 09:05:53 -0600 Subject: [vtk-developers] Parallel LIC python wrapping failure In-Reply-To: References: Message-ID: The wrappers are great for exercising class interfaces, and they don't like the fact that the ParallelLIC interface headers include vtkMPI.h. It looks like ParallelLIC is the only module that does this, even though several other modules use MPI. I'll exclude the problematic headers from wrapping. - David On Tue, Sep 29, 2015 at 6:43 AM, David Gobbi wrote: > Hi Dan, > > I've put together a wrap-exclude-python patch, but I suspect > that it won't fix the issue: > https://gitlab.kitware.com/vtk/vtk/merge_requests/709 > > It's possible that vtk_mpi_link(${vtk-module}PythonD) would > do what's needed, but it's strange that the other parallel modules > build fine without explicitly linking the wrappers to MPI. > > - David > > On Mon, Sep 28, 2015 at 4:08 PM, Dan Lipsa wrote: > >> Hi David and all, >> We get the following build error on VTK master which seems related to the >> python wrapping >> >> https://open.cdash.org/viewBuildError.php?buildid=4034719 >> >> >> to get this, you'll need to enable python and vtkRenderingParallelLIC. >> >> I think the vtkRenderingParallelLICPythonD library just needs mpi and >> mpi_cxx libraries but I am not sure how to pass them to the wrapping code. >> >> vtkRenderingParallelLIC link privately with this libraries so this is no >> help to vtkRenderingParallelLICPythonD. >> >> >> Thanks, >> Dan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Sep 29 11:08:06 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 29 Sep 2015 11:08:06 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! In-Reply-To: References: <20150928152236.GA11816@megas.khq.kitware.com> Message-ID: <20150929150806.GB5829@megas.khq.kitware.com> On Tue, Sep 29, 2015 at 10:25:17 -0400, Utkarsh Ayachit wrote: > Can these be documented in the VTK/ParaView contributing guide please? Thanks. Yeah, I'll do that when I enable it for the rest of the projects. --Ben From ken.martin at kitware.com Tue Sep 29 11:57:50 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 29 Sep 2015 11:57:50 -0400 Subject: [vtk-developers] Fwd: Picking problem with OpenGL2 and DepthPeeling In-Reply-To: References: <4a86e1519564c55cffeef2e29171a650@mail.gmail.com> Message-ID: <51afd6505c336d3459969fd21fa7d37a@mail.gmail.com> OK I think the following topic should fix the issue. https://gitlab.kitware.com/vtk/vtk/merge_requests/706 Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Xabi Riobe *Sent:* Friday, September 25, 2015 7:50 AM *To:* VTK Developers *Subject:* [vtk-developers] Fwd: Picking problem with OpenGL2 and DepthPeeling Hi Ken, with the patch we can pick the transparent surfaces but not the opaque ones anymore. for example in the sample you can pick on the plane but not on the spheres that are created. 2015-09-24 16:37 GMT+02:00 Ken Martin : Thanks! I believe the new depth peeling code is probably leaving the zbuffer in a different state than the opaque z buffer. If you get a second could you try the attached patch and see if it works for you. It is based on a more recent VTK but it is a tiny patch. Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 919 869-8871 (w) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Xabi Riobe *Sent:* Thursday, September 24, 2015 5:29 AM *To:* VTK Developers *Subject:* [vtk-developers] Picking problem with OpenGL2 and DepthPeeling Hi, I try to pick in a scene that contains a translucent object and the pick fails if I use the OpenGL2 backend (v6.3.0), tested on VS2013 32 bits with nVidia Quadro 4000 (driver 353.30) The same code works with OpenGL backend. I can reproduce it with the sample code attached, based on the example at http://www.vtk.org/Wiki/VTK/Examples/Cxx/Interaction/Picking with these lines added: renderer->SetUseDepthPeeling(1); renderer->SetMaximumNumberOfPeels(8); renderWindow->SetAlphaBitPlanes(1); renderWindow->SetMultiSamples(0); and the opacity set to 0.5 for the plane. If i don't use depth peeling, or if the plane is opaque, the picker works as expected. It seems that the pick fails when in vtkOpenGLRenderer::DonePick the float value returned by GetZbufferData is 1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Sep 29 13:34:52 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 29 Sep 2015 13:34:52 -0400 Subject: [vtk-developers] [BUILDBOT] New buildbot features! In-Reply-To: <20150929150806.GB5829@megas.khq.kitware.com> References: <20150928152236.GA11816@megas.khq.kitware.com> <20150929150806.GB5829@megas.khq.kitware.com> Message-ID: <20150929173452.GA31828@megas.khq.kitware.com> On Tue, Sep 29, 2015 at 11:08:06 -0400, Ben Boeckel wrote: > On Tue, Sep 29, 2015 at 10:25:17 -0400, Utkarsh Ayachit wrote: > > Can these be documented in the VTK/ParaView contributing guide please? Thanks. > > Yeah, I'll do that when I enable it for the rest of the projects. https://gitlab.kitware.com/vtk/vtk/merge_requests/710 --Ben From dan.lipsa at kitware.com Tue Sep 29 13:56:21 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 29 Sep 2015 13:56:21 -0400 Subject: [vtk-developers] Parallel LIC python wrapping failure In-Reply-To: References: Message-ID: I see. That should be easy to fix if needed. Thanks for looking into this David. Dan On Tue, Sep 29, 2015 at 11:05 AM, David Gobbi wrote: > The wrappers are great for exercising class interfaces, and > they don't like the fact that the ParallelLIC interface headers > include vtkMPI.h. It looks like ParallelLIC is the only module > that does this, even though several other modules use MPI. > > I'll exclude the problematic headers from wrapping. > > - David > > On Tue, Sep 29, 2015 at 6:43 AM, David Gobbi > wrote: > >> Hi Dan, >> >> I've put together a wrap-exclude-python patch, but I suspect >> that it won't fix the issue: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/709 >> >> It's possible that vtk_mpi_link(${vtk-module}PythonD) would >> do what's needed, but it's strange that the other parallel modules >> build fine without explicitly linking the wrappers to MPI. >> >> - David >> >> On Mon, Sep 28, 2015 at 4:08 PM, Dan Lipsa wrote: >> >>> Hi David and all, >>> We get the following build error on VTK master which seems related to >>> the python wrapping >>> >>> https://open.cdash.org/viewBuildError.php?buildid=4034719 >>> >>> >>> to get this, you'll need to enable python and vtkRenderingParallelLIC. >>> >>> I think the vtkRenderingParallelLICPythonD library just needs mpi and >>> mpi_cxx libraries but I am not sure how to pass them to the wrapping code. >>> >>> vtkRenderingParallelLIC link privately with this libraries so this is no >>> help to vtkRenderingParallelLICPythonD. >>> >>> >>> Thanks, >>> Dan >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Wed Sep 30 10:50:03 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Wed, 30 Sep 2015 16:50:03 +0200 Subject: [vtk-developers] announce: VTK/ParaView Training - November 3 and 4, 2015, Lyon, France Message-ID: Kitware will be holding VTK and ParaView training courses respectively on November 3 and 4 in Lyon, France. Please visit our web site for more information and registration details at: VTK: http://formations.kitware.fr/browse/103 ParaView: http://formations.kitware.fr/browse/105 Note that the courses will be taught in English. If you have any question, please contact us at: formations at kitware.fr Thank you, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Sep 30 15:22:10 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 30 Sep 2015 15:22:10 -0400 Subject: [vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5 In-Reply-To: <20150713205134.GA14903@megas.kitware.com> References: <54E8E057.1060409@dkfz-heidelberg.de> <54F07857.4060302@dkfz-heidelberg.de> <20150713190056.GA5368@megas.kitware.com> <20150713205134.GA14903@megas.kitware.com> Message-ID: <20150930192210.GA10884@megas.khq.kitware.com> On Mon, Jul 13, 2015 at 16:51:34 -0400, Ben Boeckel wrote: > On Mon, Jul 13, 2015 at 15:00:56 -0400, Ben Boeckel wrote: > > https://codereview.qt-project.org/#/c/115531/ > > Applying this patch (with one conflicting hunk) to 5.5.0 fixes the > problem for me. I'll poke the review to see if some movement can't be > made. It looks like the patch has been merged for 5.6.0 (due at the end of October). --Ben