From andrew.amaclean at gmail.com Fri Aug 1 01:22:01 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 1 Aug 2014 15:22:01 +1000 Subject: [vtk-developers] More VTK Wiki Examples questions Message-ID: Hi David, I just compiled and ran the example on my laptop (Windows 8.1, VS 2013) using a recent checkout of the VTK Master, and I get the same image as the test image. The data file I used is the one that is downloaded into the build directory, namely the one in: \ExternalData\Testing\Data\Infovis When I build VTK, it downloads any test files and the corresponding *.md5-stamp file into this directory. Maybe VTK_DATA_STORE needs to be set to point to the ExternalData directory for CTest to work correctly. It is definitely set when CMake runs on the VTK source. I hope this helps. Regards Andrew > ---------- Forwarded message ---------- > From: David Cole > To: vtk-developers at vtk.org, jeff.baumes at kitware.com, > bill.lorensen at gmail.com > Cc: > Date: Thu, 31 Jul 2014 14:11:09 -0400 (EDT) > Subject: [vtk-developers] More VTK Wiki Examples questions > This example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader > > gets an "fsm.gml" data file from "somewhere" (but *NOT* VTKData) and uses > it when running the VTK Wiki Examples dashboard on my machine. > > > This example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/TreeMapView > > apparently depends on VTKData, which I do not have, so the test fails on > my machine. > > > On the wiki page itself, there's a note saying we should generate an > example tree map instead of loading from a data file: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/TreeMapView > > > So... we can fix the failing test by making the TreeMapView's data files > available (as fsm.gml is already available) to my dashboard build.... or by > modifying the TreeMapView example to use some generated data. Which is > easier? > > I'm not sure how to do either myself -- I'm hoping Bill L. can easily add > some data for this example, or Jeff Baumes can point me to how to generate > an example TreeMap easily... > > > Thanks, > David C. > > > > > ---------- Forwarded message ---------- > From: David Cole > To: vtk-developers at vtk.org, jeff.baumes at kitware.com > Cc: > Date: Thu, 31 Jul 2014 14:20:57 -0400 (EDT) > Subject: [vtk-developers] InfoVis graph visualization question: > vtkGraphLayoutView with a "Simple 2D" layout strategy > This VTK wiki example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader > > Yields this different rendering test failure on my dashboard machine: > http://open.cdash.org/testDetails.php?test=271695203&build=3430870 > > The graph structure looks the same, and the visual is roughly equivalent, > but the expected image clearly shows a perfectly square glyph at each graph > node. In my test image, the graph nodes look like they vary from circle to > square to polygons in between... > > What determines the shape of the node glyph in a vtkGraphLayoutView with a > "Simple 2D" layout strategy? And would the shape difference account > entirely for the slight offset and angle between expected image and test > image...? > > > Thanks, > David C. > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Fri Aug 1 07:38:53 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 07:38:53 -0400 (EDT) Subject: [vtk-developers] More VTK Wiki Examples questions Message-ID: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> > I just compiled and ran the example on my laptop (Windows 8.1, VS > 2013) using a recent checkout of the VTK Master, and I get the same > image as the test image. Thanks -- after reading through http://www.vtk.org/Wiki/VTK/Examples/Instructions/ForAdministrators it appears that in order to run a test that requires data files as arguments, the git repo for the wiki examples at git://gitorious.org/vtkwikiexamples/wikiexamples.git has to be modified manually. I'll see if I can add a topic that adds the required data files for the TreeMap example so the test can pass on my machine. If I can get it to work, I'll push it and send a pull request to Bill L. to get it into the official repo. Thanks for checking and verifying that it works for you. D From dlrdave at aol.com Fri Aug 1 07:46:00 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 07:46:00 -0400 (EDT) Subject: [vtk-developers] More VTK Wiki Examples questions In-Reply-To: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> References: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> Message-ID: <8D17B954CDDF024-BD0-158A3@webmail-d258.sysops.aol.com> My main point with this thread is: The TreeMap example test passes *accidentally* on Bill's dashboards because he has an old VTKData lying around and the example is picking up the input files from VTKData... On my dashboard machine without any VTKData directories anywhere, the test fails because the Wiki Examples git repo does not contain these data files yet. D From dave.demarle at kitware.com Tue Aug 5 13:47:43 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 5 Aug 2014 13:47:43 -0400 Subject: [vtk-developers] any volunteers for vtk qt examples issues? Message-ID: We turned kargad continuous's examples ON on 4/21, and ever since then it has had 8 qt related build errors. Any volunteers out there to fix them? http://open.cdash.org/viewBuildError.php?buildid=3302083 I'm all for updating the qt we use there if that is all it takes. 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 andrew.amaclean at gmail.com Tue Aug 5 19:32:03 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 6 Aug 2014 09:32:03 +1000 Subject: [vtk-developers] VTK Code Formatting Styles Message-ID: Has anyone got: 1) A code style for QT Creator for VTK? 2) Also one for Eclipse? If so would they be willing to share/put up in the Wiki? Thanks Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Aug 5 20:59:02 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 5 Aug 2014 20:59:02 -0400 Subject: [vtk-developers] [vtkusers] VTK Code Formatting Styles In-Reply-To: References: Message-ID: I use this for eclipse. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 5, 2014 at 7:32 PM, Andrew Maclean wrote: > Has anyone got: > 1) A code style for QT Creator for VTK? > 2) Also one for Eclipse? > If so would they be willing to share/put up in the Wiki? > > Thanks > Andrew > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kw_eclipse_style.xml Type: text/xml Size: 17590 bytes Desc: not available URL: From andrew.amaclean at gmail.com Tue Aug 5 21:37:23 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 6 Aug 2014 11:37:23 +1000 Subject: [vtk-developers] [vtkusers] VTK Code Formatting Styles In-Reply-To: References: Message-ID: Thanks David, This is much appreciated. Regards Andrew On Wed, Aug 6, 2014 at 10:59 AM, David E DeMarle wrote: > I use this for eclipse. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Tue, Aug 5, 2014 at 7:32 PM, Andrew Maclean > wrote: > >> Has anyone got: >> 1) A code style for QT Creator for VTK? >> 2) Also one for Eclipse? >> If so would they be willing to share/put up in the Wiki? >> >> Thanks >> Andrew >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.fuger at outlook.com Thu Aug 7 05:03:29 2014 From: markus.fuger at outlook.com (Markus Fuger) Date: Thu, 7 Aug 2014 11:03:29 +0200 Subject: [vtk-developers] Unexpected behaviour of vtkTransformFilter In-Reply-To: References: Message-ID: Hello, I am not entirely sure if I found a bug - but at least it is a behavior I did not expect like that. I do have a vtkUnstructuredGrid object with a 3 component vector as point data. If I apply the vtkTransformFilter with a scaling of - let's say 1000 - in each direction. not only the coordinates get scaled but as well the values within the point data array. Due to the fact, that this data could be a physical value or whatsoever I believe that this is a bug. (I am using vtk6.2 from July 22nd 2014) I could repeat this problem as well in the latest release version of ParaView (4.1). Could perhaps one of the vtk-developers confirm that this is a bug or that this behavior is wanted - because I will then need to change my code. With kind regards, Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Aug 7 07:47:04 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 7 Aug 2014 07:47:04 -0400 Subject: [vtk-developers] Unexpected behaviour of vtkTransformFilter In-Reply-To: References: Message-ID: >From the documentation: // vtkTransformFilter is a filter to transform point coordinates, and // associated point normals and vectors. Other point data is passed // through the filter. On Thu, Aug 7, 2014 at 5:03 AM, Markus Fuger wrote: > Hello, > > I am not entirely sure if I found a bug - but at least it is a behavior I > did not expect like that. > I do have a vtkUnstructuredGrid object with a 3 component vector as point > data. > If I apply the vtkTransformFilter with a scaling of - let's say 1000 - in > each direction. not only the coordinates get scaled but as well the values > within the point data array. Due to the fact, that this data could be a > physical value or whatsoever I believe that this is a bug. (I am using > vtk6.2 from July 22nd 2014) > > I could repeat this problem as well in the latest release version of > ParaView (4.1). > > Could perhaps one of the vtk-developers confirm that this is a bug or that > this behavior is wanted - because I will then need to change my code. > > With kind regards, > Markus > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Fri Aug 8 09:05:19 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 8 Aug 2014 09:05:19 -0400 Subject: [vtk-developers] any volunteers for vtk qt examples issues? In-Reply-To: References: Message-ID: Turned out to be cmake 2.8.9 had a problem with CMAKE_AUTOMOC ON that Alex fixed in 2.8.10. http://public.kitware.com/Bug/view.php?id=13572 I bumped kargad to cmake 3.0.1 to fix it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 5, 2014 at 1:47 PM, David E DeMarle wrote: > We turned kargad continuous's examples ON on 4/21, and ever since then it > has had 8 qt related build errors. Any volunteers out there to fix them? > > http://open.cdash.org/viewBuildError.php?buildid=3302083 > > I'm all for updating the qt we use there if that is all it takes. > > 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 rostislav.khlebnikov at kcl.ac.uk Sat Aug 9 14:52:44 2014 From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov) Date: Sat, 9 Aug 2014 19:52:44 +0100 Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator Message-ID: <53E66DFC.201@kcl.ac.uk> Hi guys, just thought that the VTK developers might be interested in the test I made recently. Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata. Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms. The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through. But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code? All best, Rostislav. From berk.geveci at kitware.com Tue Aug 12 12:44:28 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 12 Aug 2014 12:44:28 -0400 Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator In-Reply-To: <53E66DFC.201@kcl.ac.uk> References: <53E66DFC.201@kcl.ac.uk> Message-ID: Hi Rostislav, This is great. Can you push the code to Gerrit ( http://review.source.kitware.com/)? Best, -berk On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov < rostislav.khlebnikov at kcl.ac.uk> wrote: > Hi guys, > > just thought that the VTK developers might be interested in the test I > made recently. > > Bascially what I did is subclass the vtkCellLocator to implement the > visitor pattern. It allows to filter the octree nodes (e.g. reject the > octree nodes that are of no interest early) and for leafs, to visit the > cells of the polydata. > Then, I subclassed the vtkCutter to use this cell locator instead of > straight iteration over cells. Likely for very complex implicit cutting > functions this wouldnt be of any benefit. However, for those which can test > bboxes as being of interest or not, rejecting whole subtrees, such as > vtkPlane, it is very useful. I tested it on a surface with 500k triangles > and the cutter performance went from 88ms per cut to 14ms. > > The code I made is quite ugly due to limited extensibility of vtkCutter, > so I had to copy-paste the RequestData method and make my changes instead > of, say, overriding IterateCells method which would just provide the cells > to cut through. > > But anyway, I was wondering if you guys are intersted in this kind of > functionality? Would you like me to send you the code? > > All best, > Rostislav. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodwin.lawlor.lists at gmail.com Wed Aug 13 12:08:14 2014 From: goodwin.lawlor.lists at gmail.com (Goodwin Lawlor) Date: Wed, 13 Aug 2014 17:08:14 +0100 Subject: [vtk-developers] [vtkusers] Problems with ComputeOBB - wrong OBB computed In-Reply-To: References: <1407753513395-5728174.post@n5.nabble.com> <1407848098869-5728187.post@n5.nabble.com> <1407937240013-5728206.post@n5.nabble.com> Message-ID: Would methods like: static int vtkMath::GetMean3 (vtkDataArray *array, double mean[3]) static int vtkMath::GetCovarianceMatrix (vtkDataArray *array, double mean[3], double *covariance) be a better way? Goodwin cf. for VTK devs see http://vtk.markmail.org/search/?q=#query:%20list%3Aorg.vtk.vtkusers+page:1+mid:ppj3wtbusf537spk+state:results On Wed, Aug 13, 2014 at 3:53 PM, Goodwin Lawlor < goodwin.lawlor.lists at gmail.com> wrote: > This wiki page should get you going: > http://www.vtk.org/Wiki/VTK/Git/Develop > > Goodwin > > > On Wed, Aug 13, 2014 at 2:40 PM, Oliver Weinheimer wrote: > >> Hi Goodwin, >> >> yes I also think that this change can improve accuracy also in other >> places >> in VTK. >> In my case, the mean calculation errors built up extremly, so that the >> calculated OBB was unusable. >> No, I'm not familiar with Gerrit, but I will have a look on it. >> Thanks for your reply and help. >> >> Oliver >> >> >> Goodwin Lawlor-2 wrote >> > Hi Oliver, >> > >> > That's a nice method - the mean is gradually accumulated, preserving the >> > accuracy of the floating point value. I'm sure there are other places in >> > VTK that would benefit from this code change... >> > >> > If you're familiar with Gerrit, could you submit this change? I'll have >> a >> > poke around the code base to see if there are other similar mean >> > calculations. >> > >> > Goodwin >> >> >> >> >> >> -- >> View this message in context: >> http://vtk.1045678.n5.nabble.com/Problems-with-ComputeOBB-wrong-OBB-computed-tp5728174p5728206.html >> Sent from the VTK - Users mailing list archive at Nabble.com. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinya.onogi at live.jp Thu Aug 14 01:24:05 2014 From: shinya.onogi at live.jp (Onogi Shinya) Date: Thu, 14 Aug 2014 14:24:05 +0900 Subject: [vtk-developers] vtkPistonMapper bug Message-ID: Hi all: vtkPistonMapper calls vtkpiston::CudaRegisterBuffer in every gpu rendering (in vtkPistonMapper.cxx; L181-L186); however, cudaGraphicsUnregisterResource is never called. It results in a gpu resource issue when vtkPistonAlgorithm is updated several times. Quick solution I tested is followings: vtkPistonMapper.cxx 43 void CudaRegisterBuffer(struct cudaGraphicsResource **vboResource, 44 GLuint vboBuffer); + void CudaUnregisterBuffer(struct cudaGraphicsResource **vboResource); 148 if (this->Internal->BufferSize != 0) 149?? { 150??? // Release old buffer +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[0]); +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[1]); +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[2]); 151??? vtkgl::DeleteBuffers(3, this->Internal->vboBuffers); vtkPistonMapper.cu void CudaUnregisterResource(struct cudaGraphicsResource *vboResource) { cudaError_t res = cudaGraphicsUnregisterResource(vboResource); if (res != cudaSuccess) { cerr << "Unregister buffer failed ... " << cudaGetErrorString(res) << endl; return; } } But, register/unregister in every rendering wouldn't be needed according to samples of gl interop with cuda. Thnaks, Shinya From dave.demarle at kitware.com Thu Aug 14 10:52:40 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 14 Aug 2014 10:52:40 -0400 Subject: [vtk-developers] vtkPistonMapper bug In-Reply-To: References: Message-ID: Shinya, Would you be please submit this patch to VTK's gerrit review to make it easy to test and integrate your fix? To do that (distilled from http://www.vtk.org/Wiki/VTK/Git/Develop) $ git clone git://vtk.org/VTK.git $ ./Utilities/SetupForDevelopment.sh $ git checkout -b my-topic origin/master $ edit Accelerators/Piston/vtkPistonMapper.cxx $ compile and test locally $ git add file1 file2 file3 $ git commit $ git gerrit-push Choose myself and Robert Maynard as reviewers please in the gerrit web page for the change. Thank you! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Aug 14, 2014 at 1:24 AM, Onogi Shinya wrote: > Hi all: > > vtkPistonMapper calls vtkpiston::CudaRegisterBuffer in every gpu rendering > (in vtkPistonMapper.cxx; L181-L186); however, > cudaGraphicsUnregisterResource is never called. It results in a gpu > resource issue when vtkPistonAlgorithm is updated several times. > > Quick solution I tested is followings: > vtkPistonMapper.cxx > 43 void CudaRegisterBuffer(struct cudaGraphicsResource **vboResource, > 44 GLuint vboBuffer); > + void CudaUnregisterBuffer(struct cudaGraphicsResource **vboResource); > > 148 if (this->Internal->BufferSize != 0) > 149 { > 150 // Release old buffer > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[0]); > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[1]); > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[2]); > 151 vtkgl::DeleteBuffers(3, this->Internal->vboBuffers); > > vtkPistonMapper.cu > void CudaUnregisterResource(struct cudaGraphicsResource *vboResource) > { > cudaError_t res = cudaGraphicsUnregisterResource(vboResource); > if (res != cudaSuccess) > { > cerr << "Unregister buffer failed ... " << cudaGetErrorString(res) << > endl; > return; > } > } > > But, register/unregister in every rendering wouldn't be needed according > to samples of gl interop with cuda. > Thnaks, > Shinya > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Aug 18 13:45:37 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 13:45:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: Hi, As we move forward, it would be great to get a feeling for people's thoughts about integrating some components of C++11 optionally. So if C++11 is available/enabled, there are several features we could enable optionally at compile time. A very simple example is that of the new override keyword, that is used to indicate that a member function is overriding a virtual function. Using this can avoid mistakes where the signature changes and derived classes are missed. It can be defined in a header (empty on old compilers, override with recent compilers). Final is similar, indicating that the virtual function cannot be overridden in derived classes. This would introduce changes to the VTK coding style, where we now use virtual for all virtual functions (first declaration, or subsequent overrides). We could introduce this gradually for new code, even having one or two dashboards compiling this way would help spot simple errors such as an incorrect signature not actually overriding a function, but in fact declaring a new virtual for example. In these cases I would suggest simple naming, so VTK_OVERRIDE and VTK_FINAL would be used where a C++11 only code would simply use the new keywords. Thoughts, objections? There are lots of other features, and I know it will be a while before we can use them all but it would be great to make a start with some of the easier ones that can improve code quality with little overhead. Marcus From ben.boeckel at kitware.com Mon Aug 18 14:21:56 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 18 Aug 2014 14:21:56 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140818182156.GB23226@megas.kitwarein.com> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. What about "= delete" for removing default assignment and copy constructors? --Ben From marcus.hanwell at kitware.com Mon Aug 18 14:29:10 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 14:29:10 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140818182156.GB23226@megas.kitwarein.com> References: <20140818182156.GB23226@megas.kitwarein.com> Message-ID: On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel wrote: > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > Certainly, I think we should start out simple and then build it out. If we have prototypes for a few of the most useful features that can easily be encapsulated in compile time logic that will degrade to C++98 that would be great. Marcus From sean at rogue-research.com Mon Aug 18 16:50:12 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 18 Aug 2014 16:50:12 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140818205012.958234089@mail.rogue-research.com> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >As we move forward, it would be great to get a feeling for people's >thoughts about integrating some components of C++11 optionally. So if >C++11 is available/enabled, there are several features we could enable >optionally at compile time. +1 from me. nullptr is another one that can be made to work even on older compilers with some #define glue. Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if we required C++11 and "#define override /* nothing */" as appropriate. Then when C++11 really is the minimun requirement no big find/replace is required. Just a thought. PS: I already have dashboards building as C++11 and C++14. 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 sean at rogue-research.com Mon Aug 18 17:05:38 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 18 Aug 2014 17:05:38 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140818205012.958234089@mail.rogue-research.com> References: <20140818205012.958234089@mail.rogue-research.com> Message-ID: <20140818210538.1892131851@mail.rogue-research.com> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >nullptr is another one that can be made to work even on older compilers >with some #define glue. > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >we required C++11 and "#define override /* nothing */" as appropriate. >Then when C++11 really is the minimun requirement no big find/replace is >required. Just a thought. I hit send too fast... I also wanted to suggest looking at the clang-modernize tool, which is "a standalone tool used to automatically convert C++ code written against old standards to use features of the newest C++ standard". Specifically, it can be used to automatically add 'override' and convert to 'nullptr': 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 andrew.amaclean at gmail.com Mon Aug 18 18:09:02 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 08:09:02 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: +1! ... actually: ++1 :-) I would support this. To keep VTK relevant we need to be introducing these features. Especially features like nullptr, unique_ptr etc. But I would not be happy at introducing more VTK defines like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of using a modernise tool. Regards Andrew On Tue, Aug 19, 2014 at 7:05 AM, wrote: > > ---------- Forwarded message ---------- > From: "Marcus D. Hanwell" > To: VTK Developers > Cc: > Date: Mon, 18 Aug 2014 13:45:37 -0400 > Subject: [vtk-developers] Introducing (optional) C++11 features in VTK > Hi, > > As we move forward, it would be great to get a feeling for people's > thoughts about integrating some components of C++11 optionally. So if > C++11 is available/enabled, there are several features we could enable > optionally at compile time. > > A very simple example is that of the new override keyword, that is > used to indicate that a member function is overriding a virtual > function. Using this can avoid mistakes where the signature changes > and derived classes are missed. It can be defined in a header (empty > on old compilers, override with recent compilers). Final is similar, > indicating that the virtual function cannot be overridden in derived > classes. > > This would introduce changes to the VTK coding style, where we now use > virtual for all virtual functions (first declaration, or subsequent > overrides). We could introduce this gradually for new code, even > having one or two dashboards compiling this way would help spot simple > errors such as an incorrect signature not actually overriding a > function, but in fact declaring a new virtual for example. > > In these cases I would suggest simple naming, so VTK_OVERRIDE and > VTK_FINAL would be used where a C++11 only code would simply use the > new keywords. > > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. > > Marcus > > > > ---------- Forwarded message ---------- > From: Ben Boeckel > To: "Marcus D. Hanwell" > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:21:56 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > > Thoughts, objections? There are lots of other features, and I know it > > will be a while before we can use them all but it would be great to > > make a start with some of the easier ones that can improve code > > quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > > --Ben > > > > ---------- Forwarded message ---------- > From: "Marcus D. Hanwell" > To: Ben Boeckel > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:29:10 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > wrote: > > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> Thoughts, objections? There are lots of other features, and I know it > >> will be a while before we can use them all but it would be great to > >> make a start with some of the easier ones that can improve code > >> quality with little overhead. > > > > What about "= delete" for removing default assignment and copy > > constructors? > > > Certainly, I think we should start out simple and then build it out. > If we have prototypes for a few of the most useful features that can > easily be encapsulated in compile time logic that will degrade to > C++98 that would be great. > > Marcus > > > > ---------- Forwarded message ---------- > From: "Sean McBride" > To: "Marcus D. Hanwell" , "VTK Developers" < > vtk-developers at vtk.org> > Cc: > Date: Mon, 18 Aug 2014 16:50:12 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > > >As we move forward, it would be great to get a feeling for people's > >thoughts about integrating some components of C++11 optionally. So if > >C++11 is available/enabled, there are several features we could enable > >optionally at compile time. > > +1 from me. > > nullptr is another one that can be made to work even on older compilers > with some #define glue. > > Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if > we required C++11 and "#define override /* nothing */" as appropriate. > Then when C++11 really is the minimun requirement no big find/replace is > required. Just a thought. > > PS: I already have dashboards building as C++11 and C++14. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > ---------- Forwarded message ---------- > From: "Sean McBride" > To: "Marcus D. Hanwell" , "VTK Developers" < > vtk-developers at vtk.org> > Cc: > Date: Mon, 18 Aug 2014 17:05:38 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > > >nullptr is another one that can be made to work even on older compilers > >with some #define glue. > > > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if > >we required C++11 and "#define override /* nothing */" as appropriate. > >Then when C++11 really is the minimun requirement no big find/replace is > >required. Just a thought. > > I hit send too fast... > > I also wanted to suggest looking at the clang-modernize tool, which is "a > standalone tool used to automatically convert C++ code written against old > standards to use features of the newest C++ standard". > > > > Specifically, it can be used to automatically add 'override' and convert > to 'nullptr': > > > > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Mon Aug 18 18:25:53 2014 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Mon, 18 Aug 2014 22:25:53 +0000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: Message-ID: +1 for me too. However, my vote is actually to introduce things like VTK_OVERRIDE and VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting when libraries try to get cute with changing the behavior of (or trying to emulate) keywords with preprocessor macros. It can be pretty confusing when something goes wrong, and good luck if you have to use two separate projects together that both tried to define preprocessor macros with different implementations. -Ken From: Andrew Maclean > Reply-To: "andrew.amaclean at gmail.com" > Date: Monday, August 18, 2014 4:09 PM To: VTK Developers >, "Marcus D. Hanwell" >, Ben Boeckel >, Sean McBride > Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 features in VTK +1! ... actually: ++1 :-) I would support this. To keep VTK relevant we need to be introducing these features. Especially features like nullptr, unique_ptr etc. But I would not be happy at introducing more VTK defines like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of using a modernise tool. Regards Andrew On Tue, Aug 19, 2014 at 7:05 AM, > wrote: ---------- Forwarded message ---------- From: "Marcus D. Hanwell" > To: VTK Developers > Cc: Date: Mon, 18 Aug 2014 13:45:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Hi, As we move forward, it would be great to get a feeling for people's thoughts about integrating some components of C++11 optionally. So if C++11 is available/enabled, there are several features we could enable optionally at compile time. A very simple example is that of the new override keyword, that is used to indicate that a member function is overriding a virtual function. Using this can avoid mistakes where the signature changes and derived classes are missed. It can be defined in a header (empty on old compilers, override with recent compilers). Final is similar, indicating that the virtual function cannot be overridden in derived classes. This would introduce changes to the VTK coding style, where we now use virtual for all virtual functions (first declaration, or subsequent overrides). We could introduce this gradually for new code, even having one or two dashboards compiling this way would help spot simple errors such as an incorrect signature not actually overriding a function, but in fact declaring a new virtual for example. In these cases I would suggest simple naming, so VTK_OVERRIDE and VTK_FINAL would be used where a C++11 only code would simply use the new keywords. Thoughts, objections? There are lots of other features, and I know it will be a while before we can use them all but it would be great to make a start with some of the easier ones that can improve code quality with little overhead. Marcus ---------- Forwarded message ---------- From: Ben Boeckel > To: "Marcus D. Hanwell" > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:21:56 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. What about "= delete" for removing default assignment and copy constructors? --Ben ---------- Forwarded message ---------- From: "Marcus D. Hanwell" > To: Ben Boeckel > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:29:10 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > wrote: > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > Certainly, I think we should start out simple and then build it out. If we have prototypes for a few of the most useful features that can easily be encapsulated in compile time logic that will degrade to C++98 that would be great. Marcus ---------- Forwarded message ---------- From: "Sean McBride" > To: "Marcus D. Hanwell" >, "VTK Developers" > Cc: Date: Mon, 18 Aug 2014 16:50:12 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >As we move forward, it would be great to get a feeling for people's >thoughts about integrating some components of C++11 optionally. So if >C++11 is available/enabled, there are several features we could enable >optionally at compile time. +1 from me. nullptr is another one that can be made to work even on older compilers with some #define glue. Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if we required C++11 and "#define override /* nothing */" as appropriate. Then when C++11 really is the minimun requirement no big find/replace is required. Just a thought. PS: I already have dashboards building as C++11 and C++14. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada ---------- Forwarded message ---------- From: "Sean McBride" > To: "Marcus D. Hanwell" >, "VTK Developers" > Cc: Date: Mon, 18 Aug 2014 17:05:38 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >nullptr is another one that can be made to work even on older compilers >with some #define glue. > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >we required C++11 and "#define override /* nothing */" as appropriate. >Then when C++11 really is the minimun requirement no big find/replace is >required. Just a thought. I hit send too fast... I also wanted to suggest looking at the clang-modernize tool, which is "a standalone tool used to automatically convert C++ code written against old standards to use features of the newest C++ standard". Specifically, it can be used to automatically add 'override' and convert to 'nullptr': Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Aug 18 18:29:59 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 08:29:59 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: Hi Ken Good point, thanks for that. Andrew On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth wrote: > +1 for me too. > > However, my vote is actually to introduce things like VTK_OVERRIDE and > VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting > when libraries try to get cute with changing the behavior of (or trying to > emulate) keywords with preprocessor macros. It can be pretty confusing when > something goes wrong, and good luck if you have to use two separate > projects together that both tried to define preprocessor macros with > different implementations. > > -Ken > > > From: Andrew Maclean > Reply-To: "andrew.amaclean at gmail.com" > Date: Monday, August 18, 2014 4:09 PM > To: VTK Developers , "Marcus D. Hanwell" < > marcus.hanwell at kitware.com>, Ben Boeckel , Sean > McBride > Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > features in VTK > > +1! ... actually: ++1 :-) > > I would support this. To keep VTK relevant we need to be introducing > these features. Especially features like nullptr, unique_ptr etc. > > But I would not be happy at introducing more VTK defines > like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much > prefer Sean's idea of using a modernise tool. > > Regards > Andrew > > > On Tue, Aug 19, 2014 at 7:05 AM, wrote: > >> >> ---------- Forwarded message ---------- >> From: "Marcus D. Hanwell" >> To: VTK Developers >> Cc: >> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >> Hi, >> >> As we move forward, it would be great to get a feeling for people's >> thoughts about integrating some components of C++11 optionally. So if >> C++11 is available/enabled, there are several features we could enable >> optionally at compile time. >> >> A very simple example is that of the new override keyword, that is >> used to indicate that a member function is overriding a virtual >> function. Using this can avoid mistakes where the signature changes >> and derived classes are missed. It can be defined in a header (empty >> on old compilers, override with recent compilers). Final is similar, >> indicating that the virtual function cannot be overridden in derived >> classes. >> >> This would introduce changes to the VTK coding style, where we now use >> virtual for all virtual functions (first declaration, or subsequent >> overrides). We could introduce this gradually for new code, even >> having one or two dashboards compiling this way would help spot simple >> errors such as an incorrect signature not actually overriding a >> function, but in fact declaring a new virtual for example. >> >> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> VTK_FINAL would be used where a C++11 only code would simply use the >> new keywords. >> >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. >> >> Marcus >> >> >> >> ---------- Forwarded message ---------- >> From: Ben Boeckel >> To: "Marcus D. Hanwell" >> Cc: VTK Developers >> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> > Thoughts, objections? There are lots of other features, and I know it >> > will be a while before we can use them all but it would be great to >> > make a start with some of the easier ones that can improve code >> > quality with little overhead. >> >> What about "= delete" for removing default assignment and copy >> constructors? >> >> --Ben >> >> >> >> ---------- Forwarded message ---------- >> From: "Marcus D. Hanwell" >> To: Ben Boeckel >> Cc: VTK Developers >> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> wrote: >> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >> Thoughts, objections? There are lots of other features, and I know it >> >> will be a while before we can use them all but it would be great to >> >> make a start with some of the easier ones that can improve code >> >> quality with little overhead. >> > >> > What about "= delete" for removing default assignment and copy >> > constructors? >> > >> Certainly, I think we should start out simple and then build it out. >> If we have prototypes for a few of the most useful features that can >> easily be encapsulated in compile time logic that will degrade to >> C++98 that would be great. >> >> Marcus >> >> >> >> ---------- Forwarded message ---------- >> From: "Sean McBride" >> To: "Marcus D. Hanwell" , "VTK Developers" < >> vtk-developers at vtk.org> >> Cc: >> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >> >As we move forward, it would be great to get a feeling for people's >> >thoughts about integrating some components of C++11 optionally. So if >> >C++11 is available/enabled, there are several features we could enable >> >optionally at compile time. >> >> +1 from me. >> >> nullptr is another one that can be made to work even on older compilers >> with some #define glue. >> >> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >> we required C++11 and "#define override /* nothing */" as appropriate. >> Then when C++11 really is the minimun requirement no big find/replace is >> required. Just a thought. >> >> PS: I already have dashboards building as C++11 and C++14. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Sean McBride" >> To: "Marcus D. Hanwell" , "VTK Developers" < >> vtk-developers at vtk.org> >> Cc: >> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >> >nullptr is another one that can be made to work even on older compilers >> >with some #define glue. >> > >> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >> >we required C++11 and "#define override /* nothing */" as appropriate. >> >Then when C++11 really is the minimun requirement no big find/replace is >> >required. Just a thought. >> >> I hit send too fast... >> >> I also wanted to suggest looking at the clang-modernize tool, which is "a >> standalone tool used to automatically convert C++ code written against old >> standards to use features of the newest C++ standard". >> >> >> >> Specifically, it can be used to automatically add 'override' and convert >> to 'nullptr': >> >> >> >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Aug 18 18:43:49 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 18 Aug 2014 16:43:49 -0600 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Yes, I also believe that using "#define override" has the potential to cause problems. Let's say that "override" appears as a variable somewhere in code that someone brought into VTK and tested with a C++11 compiler (this is legal, since "override" is not a keyword). Then someone else tries compiling that code on C++03 where the "#define override" is active. All of a sudden, "override" is replaced by nothing anywhere it is used as a variable (or as any other kind of identifier). On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean wrote: > Hi Ken > > Good point, thanks for that. > > Andrew > > > On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > wrote: >> >> +1 for me too. >> >> However, my vote is actually to introduce things like VTK_OVERRIDE and >> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >> when libraries try to get cute with changing the behavior of (or trying to >> emulate) keywords with preprocessor macros. It can be pretty confusing when >> something goes wrong, and good luck if you have to use two separate projects >> together that both tried to define preprocessor macros with different >> implementations. >> >> -Ken >> >> >> From: Andrew Maclean >> Reply-To: "andrew.amaclean at gmail.com" >> Date: Monday, August 18, 2014 4:09 PM >> To: VTK Developers , "Marcus D. Hanwell" >> , Ben Boeckel , Sean >> McBride >> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >> features in VTK >> >> +1! ... actually: ++1 :-) >> >> I would support this. To keep VTK relevant we need to be introducing these >> features. Especially features like nullptr, unique_ptr etc. >> >> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >> using a modernise tool. >> >> Regards >> Andrew >> >> >> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Marcus D. Hanwell" >>> To: VTK Developers >>> Cc: >>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>> Hi, >>> >>> As we move forward, it would be great to get a feeling for people's >>> thoughts about integrating some components of C++11 optionally. So if >>> C++11 is available/enabled, there are several features we could enable >>> optionally at compile time. >>> >>> A very simple example is that of the new override keyword, that is >>> used to indicate that a member function is overriding a virtual >>> function. Using this can avoid mistakes where the signature changes >>> and derived classes are missed. It can be defined in a header (empty >>> on old compilers, override with recent compilers). Final is similar, >>> indicating that the virtual function cannot be overridden in derived >>> classes. >>> >>> This would introduce changes to the VTK coding style, where we now use >>> virtual for all virtual functions (first declaration, or subsequent >>> overrides). We could introduce this gradually for new code, even >>> having one or two dashboards compiling this way would help spot simple >>> errors such as an incorrect signature not actually overriding a >>> function, but in fact declaring a new virtual for example. >>> >>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>> VTK_FINAL would be used where a C++11 only code would simply use the >>> new keywords. >>> >>> Thoughts, objections? There are lots of other features, and I know it >>> will be a while before we can use them all but it would be great to >>> make a start with some of the easier ones that can improve code >>> quality with little overhead. >>> >>> Marcus >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ben Boeckel >>> To: "Marcus D. Hanwell" >>> Cc: VTK Developers >>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> > Thoughts, objections? There are lots of other features, and I know it >>> > will be a while before we can use them all but it would be great to >>> > make a start with some of the easier ones that can improve code >>> > quality with little overhead. >>> >>> What about "= delete" for removing default assignment and copy >>> constructors? >>> >>> --Ben >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Marcus D. Hanwell" >>> To: Ben Boeckel >>> Cc: VTK Developers >>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>> wrote: >>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >> Thoughts, objections? There are lots of other features, and I know it >>> >> will be a while before we can use them all but it would be great to >>> >> make a start with some of the easier ones that can improve code >>> >> quality with little overhead. >>> > >>> > What about "= delete" for removing default assignment and copy >>> > constructors? >>> > >>> Certainly, I think we should start out simple and then build it out. >>> If we have prototypes for a few of the most useful features that can >>> easily be encapsulated in compile time logic that will degrade to >>> C++98 that would be great. >>> >>> Marcus >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Sean McBride" >>> To: "Marcus D. Hanwell" , "VTK Developers" >>> >>> Cc: >>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>> >>> >As we move forward, it would be great to get a feeling for people's >>> >thoughts about integrating some components of C++11 optionally. So if >>> >C++11 is available/enabled, there are several features we could enable >>> >optionally at compile time. >>> >>> +1 from me. >>> >>> nullptr is another one that can be made to work even on older compilers >>> with some #define glue. >>> >>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>> when C++11 really is the minimun requirement no big find/replace is >>> required. Just a thought. >>> >>> PS: I already have dashboards building as C++11 and C++14. >>> >>> Cheers, >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Sean McBride" >>> To: "Marcus D. Hanwell" , "VTK Developers" >>> >>> Cc: >>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>> >>> >nullptr is another one that can be made to work even on older compilers >>> >with some #define glue. >>> > >>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>> >we required C++11 and "#define override /* nothing */" as appropriate. >>> >Then when C++11 really is the minimun requirement no big find/replace is >>> >required. Just a thought. >>> >>> I hit send too fast... >>> >>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>> standalone tool used to automatically convert C++ code written against old >>> standards to use features of the newest C++ standard". >>> >>> >>> >>> Specifically, it can be used to automatically add 'override' and convert >>> to 'nullptr': >>> >>> >>> >>> >>> Cheers, From marcus.hanwell at kitware.com Mon Aug 18 19:25:04 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 19:25:04 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: I am with David Gobbi and Ken. It would be a simple search and replace once support for pre-C++11 compilers were dropped and the potential for unintended consequences is too great. Glad to see there is general support, I should have included more on my reasoning, but didn't want to go into too much detail on implementation if there was little support for it. It sounds like there is, nullptr is definitely another piece of low hanging fruit. There is lots more that would be great to use, the language is evolving and it is important that we take advantage of the parts that make sense. Marcus On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi wrote: > Yes, I also believe that using "#define override" has the potential to > cause problems. Let's say that "override" appears as a variable > somewhere in code that someone brought into VTK and tested with a > C++11 compiler (this is legal, since "override" is not a keyword). > Then someone else tries compiling that code on C++03 where the > "#define override" is active. All of a sudden, "override" is replaced > by nothing anywhere it is used as a variable (or as any other kind of > identifier). > > > On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > wrote: >> Hi Ken >> >> Good point, thanks for that. >> >> Andrew >> >> >> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >> wrote: >>> >>> +1 for me too. >>> >>> However, my vote is actually to introduce things like VTK_OVERRIDE and >>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >>> when libraries try to get cute with changing the behavior of (or trying to >>> emulate) keywords with preprocessor macros. It can be pretty confusing when >>> something goes wrong, and good luck if you have to use two separate projects >>> together that both tried to define preprocessor macros with different >>> implementations. >>> >>> -Ken >>> >>> >>> From: Andrew Maclean >>> Reply-To: "andrew.amaclean at gmail.com" >>> Date: Monday, August 18, 2014 4:09 PM >>> To: VTK Developers , "Marcus D. Hanwell" >>> , Ben Boeckel , Sean >>> McBride >>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>> features in VTK >>> >>> +1! ... actually: ++1 :-) >>> >>> I would support this. To keep VTK relevant we need to be introducing these >>> features. Especially features like nullptr, unique_ptr etc. >>> >>> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >>> using a modernise tool. >>> >>> Regards >>> Andrew >>> >>> >>> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Marcus D. Hanwell" >>>> To: VTK Developers >>>> Cc: >>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>>> Hi, >>>> >>>> As we move forward, it would be great to get a feeling for people's >>>> thoughts about integrating some components of C++11 optionally. So if >>>> C++11 is available/enabled, there are several features we could enable >>>> optionally at compile time. >>>> >>>> A very simple example is that of the new override keyword, that is >>>> used to indicate that a member function is overriding a virtual >>>> function. Using this can avoid mistakes where the signature changes >>>> and derived classes are missed. It can be defined in a header (empty >>>> on old compilers, override with recent compilers). Final is similar, >>>> indicating that the virtual function cannot be overridden in derived >>>> classes. >>>> >>>> This would introduce changes to the VTK coding style, where we now use >>>> virtual for all virtual functions (first declaration, or subsequent >>>> overrides). We could introduce this gradually for new code, even >>>> having one or two dashboards compiling this way would help spot simple >>>> errors such as an incorrect signature not actually overriding a >>>> function, but in fact declaring a new virtual for example. >>>> >>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>>> VTK_FINAL would be used where a C++11 only code would simply use the >>>> new keywords. >>>> >>>> Thoughts, objections? There are lots of other features, and I know it >>>> will be a while before we can use them all but it would be great to >>>> make a start with some of the easier ones that can improve code >>>> quality with little overhead. >>>> >>>> Marcus >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Ben Boeckel >>>> To: "Marcus D. Hanwell" >>>> Cc: VTK Developers >>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>> > Thoughts, objections? There are lots of other features, and I know it >>>> > will be a while before we can use them all but it would be great to >>>> > make a start with some of the easier ones that can improve code >>>> > quality with little overhead. >>>> >>>> What about "= delete" for removing default assignment and copy >>>> constructors? >>>> >>>> --Ben >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Marcus D. Hanwell" >>>> To: Ben Boeckel >>>> Cc: VTK Developers >>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>>> wrote: >>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>> >> Thoughts, objections? There are lots of other features, and I know it >>>> >> will be a while before we can use them all but it would be great to >>>> >> make a start with some of the easier ones that can improve code >>>> >> quality with little overhead. >>>> > >>>> > What about "= delete" for removing default assignment and copy >>>> > constructors? >>>> > >>>> Certainly, I think we should start out simple and then build it out. >>>> If we have prototypes for a few of the most useful features that can >>>> easily be encapsulated in compile time logic that will degrade to >>>> C++98 that would be great. >>>> >>>> Marcus >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Sean McBride" >>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>> >>>> Cc: >>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>>> >>>> >As we move forward, it would be great to get a feeling for people's >>>> >thoughts about integrating some components of C++11 optionally. So if >>>> >C++11 is available/enabled, there are several features we could enable >>>> >optionally at compile time. >>>> >>>> +1 from me. >>>> >>>> nullptr is another one that can be made to work even on older compilers >>>> with some #define glue. >>>> >>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>>> when C++11 really is the minimun requirement no big find/replace is >>>> required. Just a thought. >>>> >>>> PS: I already have dashboards building as C++11 and C++14. >>>> >>>> Cheers, >>>> >>>> -- >>>> ____________________________________________________________ >>>> Sean McBride, B. Eng sean at rogue-research.com >>>> Rogue Research www.rogue-research.com >>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>> >>>> >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Sean McBride" >>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>> >>>> Cc: >>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>>> >>>> >nullptr is another one that can be made to work even on older compilers >>>> >with some #define glue. >>>> > >>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>> >we required C++11 and "#define override /* nothing */" as appropriate. >>>> >Then when C++11 really is the minimun requirement no big find/replace is >>>> >required. Just a thought. >>>> >>>> I hit send too fast... >>>> >>>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>>> standalone tool used to automatically convert C++ code written against old >>>> standards to use features of the newest C++ standard". >>>> >>>> >>>> >>>> Specifically, it can be used to automatically add 'override' and convert >>>> to 'nullptr': >>>> >>>> >>>> >>>> >>>> Cheers, > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From matt.mccormick at kitware.com Mon Aug 18 20:19:37 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 18 Aug 2014 20:19:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: VTK_OVERRIDE would be nice, and it would be nice to macros that are similar to ITK. Currently there is ITK_OVERRIDE ITK_NOEXCEPT ITK_NULLPTR http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 Thanks, Matt On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell wrote: > I am with David Gobbi and Ken. It would be a simple search and replace > once support for pre-C++11 compilers were dropped and the potential > for unintended consequences is too great. Glad to see there is general > support, I should have included more on my reasoning, but didn't want > to go into too much detail on implementation if there was little > support for it. > > It sounds like there is, nullptr is definitely another piece of low > hanging fruit. There is lots more that would be great to use, the > language is evolving and it is important that we take advantage of the > parts that make sense. > > Marcus > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi wrote: >> Yes, I also believe that using "#define override" has the potential to >> cause problems. Let's say that "override" appears as a variable >> somewhere in code that someone brought into VTK and tested with a >> C++11 compiler (this is legal, since "override" is not a keyword). >> Then someone else tries compiling that code on C++03 where the >> "#define override" is active. All of a sudden, "override" is replaced >> by nothing anywhere it is used as a variable (or as any other kind of >> identifier). >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> wrote: >>> Hi Ken >>> >>> Good point, thanks for that. >>> >>> Andrew >>> >>> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >>> wrote: >>>> >>>> +1 for me too. >>>> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >>>> when libraries try to get cute with changing the behavior of (or trying to >>>> emulate) keywords with preprocessor macros. It can be pretty confusing when >>>> something goes wrong, and good luck if you have to use two separate projects >>>> together that both tried to define preprocessor macros with different >>>> implementations. >>>> >>>> -Ken >>>> >>>> >>>> From: Andrew Maclean >>>> Reply-To: "andrew.amaclean at gmail.com" >>>> Date: Monday, August 18, 2014 4:09 PM >>>> To: VTK Developers , "Marcus D. Hanwell" >>>> , Ben Boeckel , Sean >>>> McBride >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>>> features in VTK >>>> >>>> +1! ... actually: ++1 :-) >>>> >>>> I would support this. To keep VTK relevant we need to be introducing these >>>> features. Especially features like nullptr, unique_ptr etc. >>>> >>>> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >>>> using a modernise tool. >>>> >>>> Regards >>>> Andrew >>>> >>>> >>>> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Marcus D. Hanwell" >>>>> To: VTK Developers >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>>>> Hi, >>>>> >>>>> As we move forward, it would be great to get a feeling for people's >>>>> thoughts about integrating some components of C++11 optionally. So if >>>>> C++11 is available/enabled, there are several features we could enable >>>>> optionally at compile time. >>>>> >>>>> A very simple example is that of the new override keyword, that is >>>>> used to indicate that a member function is overriding a virtual >>>>> function. Using this can avoid mistakes where the signature changes >>>>> and derived classes are missed. It can be defined in a header (empty >>>>> on old compilers, override with recent compilers). Final is similar, >>>>> indicating that the virtual function cannot be overridden in derived >>>>> classes. >>>>> >>>>> This would introduce changes to the VTK coding style, where we now use >>>>> virtual for all virtual functions (first declaration, or subsequent >>>>> overrides). We could introduce this gradually for new code, even >>>>> having one or two dashboards compiling this way would help spot simple >>>>> errors such as an incorrect signature not actually overriding a >>>>> function, but in fact declaring a new virtual for example. >>>>> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >>>>> new keywords. >>>>> >>>>> Thoughts, objections? There are lots of other features, and I know it >>>>> will be a while before we can use them all but it would be great to >>>>> make a start with some of the easier ones that can improve code >>>>> quality with little overhead. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Ben Boeckel >>>>> To: "Marcus D. Hanwell" >>>>> Cc: VTK Developers >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>>> > Thoughts, objections? There are lots of other features, and I know it >>>>> > will be a while before we can use them all but it would be great to >>>>> > make a start with some of the easier ones that can improve code >>>>> > quality with little overhead. >>>>> >>>>> What about "= delete" for removing default assignment and copy >>>>> constructors? >>>>> >>>>> --Ben >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Marcus D. Hanwell" >>>>> To: Ben Boeckel >>>>> Cc: VTK Developers >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>>>> wrote: >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>>> >> Thoughts, objections? There are lots of other features, and I know it >>>>> >> will be a while before we can use them all but it would be great to >>>>> >> make a start with some of the easier ones that can improve code >>>>> >> quality with little overhead. >>>>> > >>>>> > What about "= delete" for removing default assignment and copy >>>>> > constructors? >>>>> > >>>>> Certainly, I think we should start out simple and then build it out. >>>>> If we have prototypes for a few of the most useful features that can >>>>> easily be encapsulated in compile time logic that will degrade to >>>>> C++98 that would be great. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Sean McBride" >>>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>>> >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>>>> >>>>> >As we move forward, it would be great to get a feeling for people's >>>>> >thoughts about integrating some components of C++11 optionally. So if >>>>> >C++11 is available/enabled, there are several features we could enable >>>>> >optionally at compile time. >>>>> >>>>> +1 from me. >>>>> >>>>> nullptr is another one that can be made to work even on older compilers >>>>> with some #define glue. >>>>> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>>>> when C++11 really is the minimun requirement no big find/replace is >>>>> required. Just a thought. >>>>> >>>>> PS: I already have dashboards building as C++11 and C++14. >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> ____________________________________________________________ >>>>> Sean McBride, B. Eng sean at rogue-research.com >>>>> Rogue Research www.rogue-research.com >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Sean McBride" >>>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>>> >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>>>> >>>>> >nullptr is another one that can be made to work even on older compilers >>>>> >with some #define glue. >>>>> > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>>> >we required C++11 and "#define override /* nothing */" as appropriate. >>>>> >Then when C++11 really is the minimun requirement no big find/replace is >>>>> >required. Just a thought. >>>>> >>>>> I hit send too fast... >>>>> >>>>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>>>> standalone tool used to automatically convert C++ code written against old >>>>> standards to use features of the newest C++ standard". >>>>> >>>>> >>>>> >>>>> Specifically, it can be used to automatically add 'override' and convert >>>>> to 'nullptr': >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From bill.lorensen at gmail.com Mon Aug 18 21:44:02 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 18 Aug 2014 21:44:02 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: +1 On Aug 18, 2014 8:26 PM, "Matt McCormick" wrote: > VTK_OVERRIDE would be nice, and it would be nice to macros that are > similar to ITK. Currently there is > > ITK_OVERRIDE > ITK_NOEXCEPT > ITK_NULLPTR > > > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > > > Thanks, > Matt > > On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > wrote: > > I am with David Gobbi and Ken. It would be a simple search and replace > > once support for pre-C++11 compilers were dropped and the potential > > for unintended consequences is too great. Glad to see there is general > > support, I should have included more on my reasoning, but didn't want > > to go into too much detail on implementation if there was little > > support for it. > > > > It sounds like there is, nullptr is definitely another piece of low > > hanging fruit. There is lots more that would be great to use, the > > language is evolving and it is important that we take advantage of the > > parts that make sense. > > > > Marcus > > > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > wrote: > >> Yes, I also believe that using "#define override" has the potential to > >> cause problems. Let's say that "override" appears as a variable > >> somewhere in code that someone brought into VTK and tested with a > >> C++11 compiler (this is legal, since "override" is not a keyword). > >> Then someone else tries compiling that code on C++03 where the > >> "#define override" is active. All of a sudden, "override" is replaced > >> by nothing anywhere it is used as a variable (or as any other kind of > >> identifier). > >> > >> > >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> wrote: > >>> Hi Ken > >>> > >>> Good point, thanks for that. > >>> > >>> Andrew > >>> > >>> > >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > >>> wrote: > >>>> > >>>> +1 for me too. > >>>> > >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and > >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > disconcerting > >>>> when libraries try to get cute with changing the behavior of (or > trying to > >>>> emulate) keywords with preprocessor macros. It can be pretty > confusing when > >>>> something goes wrong, and good luck if you have to use two separate > projects > >>>> together that both tried to define preprocessor macros with different > >>>> implementations. > >>>> > >>>> -Ken > >>>> > >>>> > >>>> From: Andrew Maclean > >>>> Reply-To: "andrew.amaclean at gmail.com" > >>>> Date: Monday, August 18, 2014 4:09 PM > >>>> To: VTK Developers , "Marcus D. Hanwell" > >>>> , Ben Boeckel , > Sean > >>>> McBride > >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > >>>> features in VTK > >>>> > >>>> +1! ... actually: ++1 :-) > >>>> > >>>> I would support this. To keep VTK relevant we need to be introducing > these > >>>> features. Especially features like nullptr, unique_ptr etc. > >>>> > >>>> But I would not be happy at introducing more VTK defines like > VTK_OVERRIDE > >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > idea of > >>>> using a modernise tool. > >>>> > >>>> Regards > >>>> Andrew > >>>> > >>>> > >>>> On Tue, Aug 19, 2014 at 7:05 AM, > wrote: > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: VTK Developers > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > VTK > >>>>> Hi, > >>>>> > >>>>> As we move forward, it would be great to get a feeling for people's > >>>>> thoughts about integrating some components of C++11 optionally. So if > >>>>> C++11 is available/enabled, there are several features we could > enable > >>>>> optionally at compile time. > >>>>> > >>>>> A very simple example is that of the new override keyword, that is > >>>>> used to indicate that a member function is overriding a virtual > >>>>> function. Using this can avoid mistakes where the signature changes > >>>>> and derived classes are missed. It can be defined in a header (empty > >>>>> on old compilers, override with recent compilers). Final is similar, > >>>>> indicating that the virtual function cannot be overridden in derived > >>>>> classes. > >>>>> > >>>>> This would introduce changes to the VTK coding style, where we now > use > >>>>> virtual for all virtual functions (first declaration, or subsequent > >>>>> overrides). We could introduce this gradually for new code, even > >>>>> having one or two dashboards compiling this way would help spot > simple > >>>>> errors such as an incorrect signature not actually overriding a > >>>>> function, but in fact declaring a new virtual for example. > >>>>> > >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >>>>> VTK_FINAL would be used where a C++11 only code would simply use the > >>>>> new keywords. > >>>>> > >>>>> Thoughts, objections? There are lots of other features, and I know it > >>>>> will be a while before we can use them all but it would be great to > >>>>> make a start with some of the easier ones that can improve code > >>>>> quality with little overhead. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: Ben Boeckel > >>>>> To: "Marcus D. Hanwell" > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> > Thoughts, objections? There are lots of other features, and I know > it > >>>>> > will be a while before we can use them all but it would be great to > >>>>> > make a start with some of the easier ones that can improve code > >>>>> > quality with little overhead. > >>>>> > >>>>> What about "= delete" for removing default assignment and copy > >>>>> constructors? > >>>>> > >>>>> --Ben > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: Ben Boeckel > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel < > ben.boeckel at kitware.com> > >>>>> wrote: > >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> >> Thoughts, objections? There are lots of other features, and I > know it > >>>>> >> will be a while before we can use them all but it would be great > to > >>>>> >> make a start with some of the easier ones that can improve code > >>>>> >> quality with little overhead. > >>>>> > > >>>>> > What about "= delete" for removing default assignment and copy > >>>>> > constructors? > >>>>> > > >>>>> Certainly, I think we should start out simple and then build it out. > >>>>> If we have prototypes for a few of the most useful features that can > >>>>> easily be encapsulated in compile time logic that will degrade to > >>>>> C++98 that would be great. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >>>>> > >>>>> >As we move forward, it would be great to get a feeling for people's > >>>>> >thoughts about integrating some components of C++11 optionally. So > if > >>>>> >C++11 is available/enabled, there are several features we could > enable > >>>>> >optionally at compile time. > >>>>> > >>>>> +1 from me. > >>>>> > >>>>> nullptr is another one that can be made to work even on older > compilers > >>>>> with some #define glue. > >>>>> > >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> we required C++11 and "#define override /* nothing */" as > appropriate. Then > >>>>> when C++11 really is the minimun requirement no big find/replace is > >>>>> required. Just a thought. > >>>>> > >>>>> PS: I already have dashboards building as C++11 and C++14. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> -- > >>>>> ____________________________________________________________ > >>>>> Sean McBride, B. Eng sean at rogue-research.com > >>>>> Rogue Research www.rogue-research.com > >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >>>>> > >>>>> >nullptr is another one that can be made to work even on older > compilers > >>>>> >with some #define glue. > >>>>> > > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> >we required C++11 and "#define override /* nothing */" as > appropriate. > >>>>> >Then when C++11 really is the minimun requirement no big > find/replace is > >>>>> >required. Just a thought. > >>>>> > >>>>> I hit send too fast... > >>>>> > >>>>> I also wanted to suggest looking at the clang-modernize tool, which > is "a > >>>>> standalone tool used to automatically convert C++ code written > against old > >>>>> standards to use features of the newest C++ standard". > >>>>> > >>>>> > >>>>> > >>>>> Specifically, it can be used to automatically add 'override' and > convert > >>>>> to 'nullptr': > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > 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 > > 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 Mon Aug 18 22:28:59 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 12:28:59 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Brilliant! It looks as if ITK has already done a lot of this! Andrew On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick wrote: > VTK_OVERRIDE would be nice, and it would be nice to macros that are > similar to ITK. Currently there is > > ITK_OVERRIDE > ITK_NOEXCEPT > ITK_NULLPTR > > > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > > > Thanks, > Matt > > On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > wrote: > > I am with David Gobbi and Ken. It would be a simple search and replace > > once support for pre-C++11 compilers were dropped and the potential > > for unintended consequences is too great. Glad to see there is general > > support, I should have included more on my reasoning, but didn't want > > to go into too much detail on implementation if there was little > > support for it. > > > > It sounds like there is, nullptr is definitely another piece of low > > hanging fruit. There is lots more that would be great to use, the > > language is evolving and it is important that we take advantage of the > > parts that make sense. > > > > Marcus > > > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > wrote: > >> Yes, I also believe that using "#define override" has the potential to > >> cause problems. Let's say that "override" appears as a variable > >> somewhere in code that someone brought into VTK and tested with a > >> C++11 compiler (this is legal, since "override" is not a keyword). > >> Then someone else tries compiling that code on C++03 where the > >> "#define override" is active. All of a sudden, "override" is replaced > >> by nothing anywhere it is used as a variable (or as any other kind of > >> identifier). > >> > >> > >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> wrote: > >>> Hi Ken > >>> > >>> Good point, thanks for that. > >>> > >>> Andrew > >>> > >>> > >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > >>> wrote: > >>>> > >>>> +1 for me too. > >>>> > >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and > >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > disconcerting > >>>> when libraries try to get cute with changing the behavior of (or > trying to > >>>> emulate) keywords with preprocessor macros. It can be pretty > confusing when > >>>> something goes wrong, and good luck if you have to use two separate > projects > >>>> together that both tried to define preprocessor macros with different > >>>> implementations. > >>>> > >>>> -Ken > >>>> > >>>> > >>>> From: Andrew Maclean > >>>> Reply-To: "andrew.amaclean at gmail.com" > >>>> Date: Monday, August 18, 2014 4:09 PM > >>>> To: VTK Developers , "Marcus D. Hanwell" > >>>> , Ben Boeckel , > Sean > >>>> McBride > >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > >>>> features in VTK > >>>> > >>>> +1! ... actually: ++1 :-) > >>>> > >>>> I would support this. To keep VTK relevant we need to be introducing > these > >>>> features. Especially features like nullptr, unique_ptr etc. > >>>> > >>>> But I would not be happy at introducing more VTK defines like > VTK_OVERRIDE > >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > idea of > >>>> using a modernise tool. > >>>> > >>>> Regards > >>>> Andrew > >>>> > >>>> > >>>> On Tue, Aug 19, 2014 at 7:05 AM, > wrote: > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: VTK Developers > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > VTK > >>>>> Hi, > >>>>> > >>>>> As we move forward, it would be great to get a feeling for people's > >>>>> thoughts about integrating some components of C++11 optionally. So if > >>>>> C++11 is available/enabled, there are several features we could > enable > >>>>> optionally at compile time. > >>>>> > >>>>> A very simple example is that of the new override keyword, that is > >>>>> used to indicate that a member function is overriding a virtual > >>>>> function. Using this can avoid mistakes where the signature changes > >>>>> and derived classes are missed. It can be defined in a header (empty > >>>>> on old compilers, override with recent compilers). Final is similar, > >>>>> indicating that the virtual function cannot be overridden in derived > >>>>> classes. > >>>>> > >>>>> This would introduce changes to the VTK coding style, where we now > use > >>>>> virtual for all virtual functions (first declaration, or subsequent > >>>>> overrides). We could introduce this gradually for new code, even > >>>>> having one or two dashboards compiling this way would help spot > simple > >>>>> errors such as an incorrect signature not actually overriding a > >>>>> function, but in fact declaring a new virtual for example. > >>>>> > >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >>>>> VTK_FINAL would be used where a C++11 only code would simply use the > >>>>> new keywords. > >>>>> > >>>>> Thoughts, objections? There are lots of other features, and I know it > >>>>> will be a while before we can use them all but it would be great to > >>>>> make a start with some of the easier ones that can improve code > >>>>> quality with little overhead. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: Ben Boeckel > >>>>> To: "Marcus D. Hanwell" > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> > Thoughts, objections? There are lots of other features, and I know > it > >>>>> > will be a while before we can use them all but it would be great to > >>>>> > make a start with some of the easier ones that can improve code > >>>>> > quality with little overhead. > >>>>> > >>>>> What about "= delete" for removing default assignment and copy > >>>>> constructors? > >>>>> > >>>>> --Ben > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: Ben Boeckel > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel < > ben.boeckel at kitware.com> > >>>>> wrote: > >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> >> Thoughts, objections? There are lots of other features, and I > know it > >>>>> >> will be a while before we can use them all but it would be great > to > >>>>> >> make a start with some of the easier ones that can improve code > >>>>> >> quality with little overhead. > >>>>> > > >>>>> > What about "= delete" for removing default assignment and copy > >>>>> > constructors? > >>>>> > > >>>>> Certainly, I think we should start out simple and then build it out. > >>>>> If we have prototypes for a few of the most useful features that can > >>>>> easily be encapsulated in compile time logic that will degrade to > >>>>> C++98 that would be great. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >>>>> > >>>>> >As we move forward, it would be great to get a feeling for people's > >>>>> >thoughts about integrating some components of C++11 optionally. So > if > >>>>> >C++11 is available/enabled, there are several features we could > enable > >>>>> >optionally at compile time. > >>>>> > >>>>> +1 from me. > >>>>> > >>>>> nullptr is another one that can be made to work even on older > compilers > >>>>> with some #define glue. > >>>>> > >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> we required C++11 and "#define override /* nothing */" as > appropriate. Then > >>>>> when C++11 really is the minimun requirement no big find/replace is > >>>>> required. Just a thought. > >>>>> > >>>>> PS: I already have dashboards building as C++11 and C++14. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> -- > >>>>> ____________________________________________________________ > >>>>> Sean McBride, B. Eng sean at rogue-research.com > >>>>> Rogue Research www.rogue-research.com > >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >>>>> > >>>>> >nullptr is another one that can be made to work even on older > compilers > >>>>> >with some #define glue. > >>>>> > > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> >we required C++11 and "#define override /* nothing */" as > appropriate. > >>>>> >Then when C++11 really is the minimun requirement no big > find/replace is > >>>>> >required. Just a thought. > >>>>> > >>>>> I hit send too fast... > >>>>> > >>>>> I also wanted to suggest looking at the clang-modernize tool, which > is "a > >>>>> standalone tool used to automatically convert C++ code written > against old > >>>>> standards to use features of the newest C++ standard". > >>>>> > >>>>> > >>>>> > >>>>> Specifically, it can be used to automatically add 'override' and > convert > >>>>> to 'nullptr': > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Aug 19 11:16:35 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 19 Aug 2014 11:16:35 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Yes, and there are more extensive examples in the Qt project (for 5+), and Boost where they both used the prefixed macro name approach. I can get some of the basics in pretty quickly as I haven't heard much opposition. Marcus On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean wrote: > Brilliant! It looks as if ITK has already done a lot of this! > > > Andrew > > > > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick > wrote: >> >> VTK_OVERRIDE would be nice, and it would be nice to macros that are >> similar to ITK. Currently there is >> >> ITK_OVERRIDE >> ITK_NOEXCEPT >> ITK_NULLPTR >> >> >> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >> >> >> Thanks, >> Matt >> >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >> wrote: >> > I am with David Gobbi and Ken. It would be a simple search and replace >> > once support for pre-C++11 compilers were dropped and the potential >> > for unintended consequences is too great. Glad to see there is general >> > support, I should have included more on my reasoning, but didn't want >> > to go into too much detail on implementation if there was little >> > support for it. >> > >> > It sounds like there is, nullptr is definitely another piece of low >> > hanging fruit. There is lots more that would be great to use, the >> > language is evolving and it is important that we take advantage of the >> > parts that make sense. >> > >> > Marcus >> > >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >> > wrote: >> >> Yes, I also believe that using "#define override" has the potential to >> >> cause problems. Let's say that "override" appears as a variable >> >> somewhere in code that someone brought into VTK and tested with a >> >> C++11 compiler (this is legal, since "override" is not a keyword). >> >> Then someone else tries compiling that code on C++03 where the >> >> "#define override" is active. All of a sudden, "override" is replaced >> >> by nothing anywhere it is used as a variable (or as any other kind of >> >> identifier). >> >> >> >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> >> wrote: >> >>> Hi Ken >> >>> >> >>> Good point, thanks for that. >> >>> >> >>> Andrew >> >>> >> >>> >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >> >>> wrote: >> >>>> >> >>>> +1 for me too. >> >>>> >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >> >>>> and >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >> >>>> disconcerting >> >>>> when libraries try to get cute with changing the behavior of (or >> >>>> trying to >> >>>> emulate) keywords with preprocessor macros. It can be pretty >> >>>> confusing when >> >>>> something goes wrong, and good luck if you have to use two separate >> >>>> projects >> >>>> together that both tried to define preprocessor macros with different >> >>>> implementations. >> >>>> >> >>>> -Ken >> >>>> >> >>>> >> >>>> From: Andrew Maclean >> >>>> Reply-To: "andrew.amaclean at gmail.com" >> >>>> Date: Monday, August 18, 2014 4:09 PM >> >>>> To: VTK Developers , "Marcus D. Hanwell" >> >>>> , Ben Boeckel , >> >>>> Sean >> >>>> McBride >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >> >>>> features in VTK >> >>>> >> >>>> +1! ... actually: ++1 :-) >> >>>> >> >>>> I would support this. To keep VTK relevant we need to be introducing >> >>>> these >> >>>> features. Especially features like nullptr, unique_ptr etc. >> >>>> >> >>>> But I would not be happy at introducing more VTK defines like >> >>>> VTK_OVERRIDE >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >> >>>> idea of >> >>>> using a modernise tool. >> >>>> >> >>>> Regards >> >>>> Andrew >> >>>> >> >>>> >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >> >>>> wrote: >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Marcus D. Hanwell" >> >>>>> To: VTK Developers >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in >> >>>>> VTK >> >>>>> Hi, >> >>>>> >> >>>>> As we move forward, it would be great to get a feeling for people's >> >>>>> thoughts about integrating some components of C++11 optionally. So >> >>>>> if >> >>>>> C++11 is available/enabled, there are several features we could >> >>>>> enable >> >>>>> optionally at compile time. >> >>>>> >> >>>>> A very simple example is that of the new override keyword, that is >> >>>>> used to indicate that a member function is overriding a virtual >> >>>>> function. Using this can avoid mistakes where the signature changes >> >>>>> and derived classes are missed. It can be defined in a header (empty >> >>>>> on old compilers, override with recent compilers). Final is similar, >> >>>>> indicating that the virtual function cannot be overridden in derived >> >>>>> classes. >> >>>>> >> >>>>> This would introduce changes to the VTK coding style, where we now >> >>>>> use >> >>>>> virtual for all virtual functions (first declaration, or subsequent >> >>>>> overrides). We could introduce this gradually for new code, even >> >>>>> having one or two dashboards compiling this way would help spot >> >>>>> simple >> >>>>> errors such as an incorrect signature not actually overriding a >> >>>>> function, but in fact declaring a new virtual for example. >> >>>>> >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >> >>>>> new keywords. >> >>>>> >> >>>>> Thoughts, objections? There are lots of other features, and I know >> >>>>> it >> >>>>> will be a while before we can use them all but it would be great to >> >>>>> make a start with some of the easier ones that can improve code >> >>>>> quality with little overhead. >> >>>>> >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: Ben Boeckel >> >>>>> To: "Marcus D. Hanwell" >> >>>>> Cc: VTK Developers >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >>>>> > Thoughts, objections? There are lots of other features, and I know >> >>>>> > it >> >>>>> > will be a while before we can use them all but it would be great >> >>>>> > to >> >>>>> > make a start with some of the easier ones that can improve code >> >>>>> > quality with little overhead. >> >>>>> >> >>>>> What about "= delete" for removing default assignment and copy >> >>>>> constructors? >> >>>>> >> >>>>> --Ben >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Marcus D. Hanwell" >> >>>>> To: Ben Boeckel >> >>>>> Cc: VTK Developers >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> >>>>> >> >>>>> wrote: >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >>>>> >> Thoughts, objections? There are lots of other features, and I >> >>>>> >> know it >> >>>>> >> will be a while before we can use them all but it would be great >> >>>>> >> to >> >>>>> >> make a start with some of the easier ones that can improve code >> >>>>> >> quality with little overhead. >> >>>>> > >> >>>>> > What about "= delete" for removing default assignment and copy >> >>>>> > constructors? >> >>>>> > >> >>>>> Certainly, I think we should start out simple and then build it out. >> >>>>> If we have prototypes for a few of the most useful features that can >> >>>>> easily be encapsulated in compile time logic that will degrade to >> >>>>> C++98 that would be great. >> >>>>> >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Sean McBride" >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >>>>> Developers" >> >>>>> >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >>>>> >> >>>>> >As we move forward, it would be great to get a feeling for people's >> >>>>> >thoughts about integrating some components of C++11 optionally. So >> >>>>> > if >> >>>>> >C++11 is available/enabled, there are several features we could >> >>>>> > enable >> >>>>> >optionally at compile time. >> >>>>> >> >>>>> +1 from me. >> >>>>> >> >>>>> nullptr is another one that can be made to work even on older >> >>>>> compilers >> >>>>> with some #define glue. >> >>>>> >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >> >>>>> as if >> >>>>> we required C++11 and "#define override /* nothing */" as >> >>>>> appropriate. Then >> >>>>> when C++11 really is the minimun requirement no big find/replace is >> >>>>> required. Just a thought. >> >>>>> >> >>>>> PS: I already have dashboards building as C++11 and C++14. >> >>>>> >> >>>>> Cheers, >> >>>>> >> >>>>> -- >> >>>>> ____________________________________________________________ >> >>>>> Sean McBride, B. Eng sean at rogue-research.com >> >>>>> Rogue Research www.rogue-research.com >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Sean McBride" >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >>>>> Developers" >> >>>>> >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >>>>> >> >>>>> >nullptr is another one that can be made to work even on older >> >>>>> > compilers >> >>>>> >with some #define glue. >> >>>>> > >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >> >>>>> > as if >> >>>>> >we required C++11 and "#define override /* nothing */" as >> >>>>> > appropriate. >> >>>>> >Then when C++11 really is the minimun requirement no big >> >>>>> > find/replace is >> >>>>> >required. Just a thought. >> >>>>> >> >>>>> I hit send too fast... >> >>>>> >> >>>>> I also wanted to suggest looking at the clang-modernize tool, which >> >>>>> is "a >> >>>>> standalone tool used to automatically convert C++ code written >> >>>>> against old >> >>>>> standards to use features of the newest C++ standard". >> >>>>> >> >>>>> >> >>>>> >> >>>>> Specifically, it can be used to automatically add 'override' and >> >>>>> convert >> >>>>> to 'nullptr': >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Cheers, >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> 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 >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ From aashish.chaudhary at kitware.com Tue Aug 19 15:52:52 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 15:52:52 -0400 Subject: [vtk-developers] Broken offscreen example Message-ID: vtkImagingFactory does not exists any more. I am going to update this example unless I hear otherwise. http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/OffScreenRendering - aashish -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue Aug 19 16:06:41 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 16:06:41 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: On this note, actually I might remove it altogether if that's Ok. - Aashish On Tue, Aug 19, 2014 at 3:52 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > vtkImagingFactory does not exists any more. I am going to update this > example unless I hear otherwise. > > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/OffScreenRendering > > - aashish > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Tue Aug 19 16:18:06 2014 From: daviddoria at gmail.com (David Doria) Date: Tue, 19 Aug 2014 16:18:06 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > On this note, actually I might remove it altogether if that's Ok. > > - Aashish > It seems to me that rendering to a file is an important part of some workflows (scripts that generate a sequence of renderings, etc.). I would vote to not remove it. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue Aug 19 16:22:29 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 16:22:29 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Sure but the test name and the description is not right. I am ok with creating a new test with the right name for the purpose you mentioned. Makes sense? - Aashish On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: > On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> On this note, actually I might remove it altogether if that's Ok. >> >> - Aashish >> > > It seems to me that rendering to a file is an important part of some > workflows (scripts that generate a sequence of renderings, etc.). I would > vote to not remove it. > > David > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 19 16:33:48 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:33:48 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Works for me. On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary wrote: > Sure but the test name and the description is not right. I am ok with > creating a new test with the right name for the purpose you mentioned. > > Makes sense? > > - Aashish > > > On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >> >> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >> wrote: >>> >>> On this note, actually I might remove it altogether if that's Ok. >>> >>> - Aashish >> >> >> It seems to me that rendering to a file is an important part of some >> workflows (scripts that generate a sequence of renderings, etc.). I would >> vote to not remove it. >> >> David > > > > > -- > | 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Tue Aug 19 16:35:04 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:35:04 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: And passes on these nightly dashboards: http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen wrote: > Works for me. > > On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary > wrote: >> Sure but the test name and the description is not right. I am ok with >> creating a new test with the right name for the purpose you mentioned. >> >> Makes sense? >> >> - Aashish >> >> >> On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >>> >>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >>> wrote: >>>> >>>> On this note, actually I might remove it altogether if that's Ok. >>>> >>>> - Aashish >>> >>> >>> It seems to me that rendering to a file is an important part of some >>> workflows (scripts that generate a sequence of renderings, etc.). I would >>> vote to not remove it. >>> >>> David >> >> >> >> >> -- >> | 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 >> >> 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 bill.lorensen at gmail.com Tue Aug 19 16:37:05 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:37:05 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Requires vtk 5.10 On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen wrote: > And passes on these nightly dashboards: > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 > > > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen wrote: >> Works for me. >> >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary >> wrote: >>> Sure but the test name and the description is not right. I am ok with >>> creating a new test with the right name for the purpose you mentioned. >>> >>> Makes sense? >>> >>> - Aashish >>> >>> >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >>>> >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >>>> wrote: >>>>> >>>>> On this note, actually I might remove it altogether if that's Ok. >>>>> >>>>> - Aashish >>>> >>>> >>>> It seems to me that rendering to a file is an important part of some >>>> workflows (scripts that generate a sequence of renderings, etc.). I would >>>> vote to not remove it. >>>> >>>> David >>> >>> >>> >>> >>> -- >>> | 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 >>> >>> 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 -- Unpaid intern in BillsBasement at noware dot com From aashish.chaudhary at kitware.com Tue Aug 19 17:38:32 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 17:38:32 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Right. Sorry, I didn't quite say it right. I meant that for version 6 or higher, this example is not relevant. It does have the preprocessors but I am wondering if we need better message or just point to the fact that osmesa is compile time only. If we want to keep it like this, then I can add some text in the description. - Aashish On Tue, Aug 19, 2014 at 4:37 PM, Bill Lorensen wrote: > Requires vtk 5.10 > > > On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen > wrote: > > And passes on these nightly dashboards: > > > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 > > > > > > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen > wrote: > >> Works for me. > >> > >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary > >> wrote: > >>> Sure but the test name and the description is not right. I am ok with > >>> creating a new test with the right name for the purpose you mentioned. > >>> > >>> Makes sense? > >>> > >>> - Aashish > >>> > >>> > >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria > wrote: > >>>> > >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary > >>>> wrote: > >>>>> > >>>>> On this note, actually I might remove it altogether if that's Ok. > >>>>> > >>>>> - Aashish > >>>> > >>>> > >>>> It seems to me that rendering to a file is an important part of some > >>>> workflows (scripts that generate a sequence of renderings, etc.). I > would > >>>> vote to not remove it. > >>>> > >>>> David > >>> > >>> > >>> > >>> > >>> -- > >>> | 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 > >>> > >>> 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 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 19 17:57:19 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 17:57:19 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: I agree.We should describe how to use osmesa to accomplish offscreen mesa. On Tue, Aug 19, 2014 at 5:38 PM, Aashish Chaudhary wrote: > Right. Sorry, I didn't quite say it right. I meant that for version 6 or > higher, this example is not relevant. It does have the preprocessors but I > am wondering if we need better message or > just point to the fact that osmesa is compile time only. > > If we want to keep it like this, then I can add some text in the > description. > > - Aashish > > > On Tue, Aug 19, 2014 at 4:37 PM, Bill Lorensen > wrote: >> >> Requires vtk 5.10 >> >> >> On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen >> wrote: >> > And passes on these nightly dashboards: >> > >> > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 >> > >> > >> > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen >> > wrote: >> >> Works for me. >> >> >> >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary >> >> wrote: >> >>> Sure but the test name and the description is not right. I am ok with >> >>> creating a new test with the right name for the purpose you mentioned. >> >>> >> >>> Makes sense? >> >>> >> >>> - Aashish >> >>> >> >>> >> >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria >> >>> wrote: >> >>>> >> >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >> >>>> wrote: >> >>>>> >> >>>>> On this note, actually I might remove it altogether if that's Ok. >> >>>>> >> >>>>> - Aashish >> >>>> >> >>>> >> >>>> It seems to me that rendering to a file is an important part of some >> >>>> workflows (scripts that generate a sequence of renderings, etc.). I >> >>>> would >> >>>> vote to not remove it. >> >>>> >> >>>> David >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> | 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 >> >>> >> >>> 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 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html -- Unpaid intern in BillsBasement at noware dot com From jchris.fillionr at kitware.com Wed Aug 20 17:24:50 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 20 Aug 2014 17:24:50 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: +1 On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > Yes, and there are more extensive examples in the Qt project (for 5+), > and Boost where they both used the prefixed macro name approach. I can > get some of the basics in pretty quickly as I haven't heard much > opposition. > > Marcus > > On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean > wrote: > > Brilliant! It looks as if ITK has already done a lot of this! > > > > > > Andrew > > > > > > > > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick > > wrote: > >> > >> VTK_OVERRIDE would be nice, and it would be nice to macros that are > >> similar to ITK. Currently there is > >> > >> ITK_OVERRIDE > >> ITK_NOEXCEPT > >> ITK_NULLPTR > >> > >> > >> > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > >> > >> > >> Thanks, > >> Matt > >> > >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > >> wrote: > >> > I am with David Gobbi and Ken. It would be a simple search and replace > >> > once support for pre-C++11 compilers were dropped and the potential > >> > for unintended consequences is too great. Glad to see there is general > >> > support, I should have included more on my reasoning, but didn't want > >> > to go into too much detail on implementation if there was little > >> > support for it. > >> > > >> > It sounds like there is, nullptr is definitely another piece of low > >> > hanging fruit. There is lots more that would be great to use, the > >> > language is evolving and it is important that we take advantage of the > >> > parts that make sense. > >> > > >> > Marcus > >> > > >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > >> > wrote: > >> >> Yes, I also believe that using "#define override" has the potential > to > >> >> cause problems. Let's say that "override" appears as a variable > >> >> somewhere in code that someone brought into VTK and tested with a > >> >> C++11 compiler (this is legal, since "override" is not a keyword). > >> >> Then someone else tries compiling that code on C++03 where the > >> >> "#define override" is active. All of a sudden, "override" is > replaced > >> >> by nothing anywhere it is used as a variable (or as any other kind of > >> >> identifier). > >> >> > >> >> > >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> >> wrote: > >> >>> Hi Ken > >> >>> > >> >>> Good point, thanks for that. > >> >>> > >> >>> Andrew > >> >>> > >> >>> > >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth < > kmorel at sandia.gov> > >> >>> wrote: > >> >>>> > >> >>>> +1 for me too. > >> >>>> > >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE > >> >>>> and > >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > >> >>>> disconcerting > >> >>>> when libraries try to get cute with changing the behavior of (or > >> >>>> trying to > >> >>>> emulate) keywords with preprocessor macros. It can be pretty > >> >>>> confusing when > >> >>>> something goes wrong, and good luck if you have to use two separate > >> >>>> projects > >> >>>> together that both tried to define preprocessor macros with > different > >> >>>> implementations. > >> >>>> > >> >>>> -Ken > >> >>>> > >> >>>> > >> >>>> From: Andrew Maclean > >> >>>> Reply-To: "andrew.amaclean at gmail.com" > >> >>>> Date: Monday, August 18, 2014 4:09 PM > >> >>>> To: VTK Developers , "Marcus D. Hanwell" > >> >>>> , Ben Boeckel >, > >> >>>> Sean > >> >>>> McBride > >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) > C++11 > >> >>>> features in VTK > >> >>>> > >> >>>> +1! ... actually: ++1 :-) > >> >>>> > >> >>>> I would support this. To keep VTK relevant we need to be > introducing > >> >>>> these > >> >>>> features. Especially features like nullptr, unique_ptr etc. > >> >>>> > >> >>>> But I would not be happy at introducing more VTK defines like > >> >>>> VTK_OVERRIDE > >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > >> >>>> idea of > >> >>>> using a modernise tool. > >> >>>> > >> >>>> Regards > >> >>>> Andrew > >> >>>> > >> >>>> > >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, > >> >>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Marcus D. Hanwell" > >> >>>>> To: VTK Developers > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > >> >>>>> VTK > >> >>>>> Hi, > >> >>>>> > >> >>>>> As we move forward, it would be great to get a feeling for > people's > >> >>>>> thoughts about integrating some components of C++11 optionally. So > >> >>>>> if > >> >>>>> C++11 is available/enabled, there are several features we could > >> >>>>> enable > >> >>>>> optionally at compile time. > >> >>>>> > >> >>>>> A very simple example is that of the new override keyword, that is > >> >>>>> used to indicate that a member function is overriding a virtual > >> >>>>> function. Using this can avoid mistakes where the signature > changes > >> >>>>> and derived classes are missed. It can be defined in a header > (empty > >> >>>>> on old compilers, override with recent compilers). Final is > similar, > >> >>>>> indicating that the virtual function cannot be overridden in > derived > >> >>>>> classes. > >> >>>>> > >> >>>>> This would introduce changes to the VTK coding style, where we now > >> >>>>> use > >> >>>>> virtual for all virtual functions (first declaration, or > subsequent > >> >>>>> overrides). We could introduce this gradually for new code, even > >> >>>>> having one or two dashboards compiling this way would help spot > >> >>>>> simple > >> >>>>> errors such as an incorrect signature not actually overriding a > >> >>>>> function, but in fact declaring a new virtual for example. > >> >>>>> > >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use > the > >> >>>>> new keywords. > >> >>>>> > >> >>>>> Thoughts, objections? There are lots of other features, and I know > >> >>>>> it > >> >>>>> will be a while before we can use them all but it would be great > to > >> >>>>> make a start with some of the easier ones that can improve code > >> >>>>> quality with little overhead. > >> >>>>> > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: Ben Boeckel > >> >>>>> To: "Marcus D. Hanwell" > >> >>>>> Cc: VTK Developers > >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> >>>>> > Thoughts, objections? There are lots of other features, and I > know > >> >>>>> > it > >> >>>>> > will be a while before we can use them all but it would be great > >> >>>>> > to > >> >>>>> > make a start with some of the easier ones that can improve code > >> >>>>> > quality with little overhead. > >> >>>>> > >> >>>>> What about "= delete" for removing default assignment and copy > >> >>>>> constructors? > >> >>>>> > >> >>>>> --Ben > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Marcus D. Hanwell" > >> >>>>> To: Ben Boeckel > >> >>>>> Cc: VTK Developers > >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > >> >>>>> > >> >>>>> wrote: > >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> >>>>> >> Thoughts, objections? There are lots of other features, and I > >> >>>>> >> know it > >> >>>>> >> will be a while before we can use them all but it would be > great > >> >>>>> >> to > >> >>>>> >> make a start with some of the easier ones that can improve code > >> >>>>> >> quality with little overhead. > >> >>>>> > > >> >>>>> > What about "= delete" for removing default assignment and copy > >> >>>>> > constructors? > >> >>>>> > > >> >>>>> Certainly, I think we should start out simple and then build it > out. > >> >>>>> If we have prototypes for a few of the most useful features that > can > >> >>>>> easily be encapsulated in compile time logic that will degrade to > >> >>>>> C++98 that would be great. > >> >>>>> > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Sean McBride" > >> >>>>> To: "Marcus D. Hanwell" , "VTK > >> >>>>> Developers" > >> >>>>> > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >> >>>>> > >> >>>>> >As we move forward, it would be great to get a feeling for > people's > >> >>>>> >thoughts about integrating some components of C++11 optionally. > So > >> >>>>> > if > >> >>>>> >C++11 is available/enabled, there are several features we could > >> >>>>> > enable > >> >>>>> >optionally at compile time. > >> >>>>> > >> >>>>> +1 from me. > >> >>>>> > >> >>>>> nullptr is another one that can be made to work even on older > >> >>>>> compilers > >> >>>>> with some #define glue. > >> >>>>> > >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > >> >>>>> as if > >> >>>>> we required C++11 and "#define override /* nothing */" as > >> >>>>> appropriate. Then > >> >>>>> when C++11 really is the minimun requirement no big find/replace > is > >> >>>>> required. Just a thought. > >> >>>>> > >> >>>>> PS: I already have dashboards building as C++11 and C++14. > >> >>>>> > >> >>>>> Cheers, > >> >>>>> > >> >>>>> -- > >> >>>>> ____________________________________________________________ > >> >>>>> Sean McBride, B. Eng sean at rogue-research.com > >> >>>>> Rogue Research www.rogue-research.com > >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Sean McBride" > >> >>>>> To: "Marcus D. Hanwell" , "VTK > >> >>>>> Developers" > >> >>>>> > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >> >>>>> > >> >>>>> >nullptr is another one that can be made to work even on older > >> >>>>> > compilers > >> >>>>> >with some #define glue. > >> >>>>> > > >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use > 'override' > >> >>>>> > as if > >> >>>>> >we required C++11 and "#define override /* nothing */" as > >> >>>>> > appropriate. > >> >>>>> >Then when C++11 really is the minimun requirement no big > >> >>>>> > find/replace is > >> >>>>> >required. Just a thought. > >> >>>>> > >> >>>>> I hit send too fast... > >> >>>>> > >> >>>>> I also wanted to suggest looking at the clang-modernize tool, > which > >> >>>>> is "a > >> >>>>> standalone tool used to automatically convert C++ code written > >> >>>>> against old > >> >>>>> standards to use features of the newest C++ standard". > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> Specifically, it can be used to automatically add 'override' and > >> >>>>> convert > >> >>>>> to 'nullptr': > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> Cheers, > >> >> _______________________________________________ > >> >> Powered by www.kitware.com > >> >> > >> >> Visit other Kitware open-source projects at > >> >> http://www.kitware.com/opensource/opensource.html > >> >> > >> >> 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 > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > > > > -- > > ___________________________________________ > > Andrew J. P. Maclean > > > > ___________________________________________ > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Aug 20 18:39:34 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 21 Aug 2014 08:39:34 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: (I have already shared this with Marcus) To help the process along I did a cursory search and found these links: C++11 Detection with CMake: http://pageant.ghulbus.eu/?p=664 And down in the notes there is a comment from Rolf Eike Beer: I have pushed a repository for this module online. I have incorporated some of your changes, especially the 3 new tests. git clone git://anongit.kde.org/scratch/dakon/cmake-cxx11 This could make a really good basis for the C++11 implementation. I checked out the repository and it seems to work, read CheckCX11features.cmake it creates lots of variables called HAS_CXX11_* e.g. HAS_CXX11_LAMBDA Regards Andrew On Thu, Aug 21, 2014 at 7:24 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > +1 > > > On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> Yes, and there are more extensive examples in the Qt project (for 5+), >> and Boost where they both used the prefixed macro name approach. I can >> get some of the basics in pretty quickly as I haven't heard much >> opposition. >> >> Marcus >> >> On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean >> wrote: >> > Brilliant! It looks as if ITK has already done a lot of this! >> > >> > >> > Andrew >> > >> > >> > >> > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick >> > wrote: >> >> >> >> VTK_OVERRIDE would be nice, and it would be nice to macros that are >> >> similar to ITK. Currently there is >> >> >> >> ITK_OVERRIDE >> >> ITK_NOEXCEPT >> >> ITK_NULLPTR >> >> >> >> >> >> >> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >> >> >> >> >> >> Thanks, >> >> Matt >> >> >> >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >> >> wrote: >> >> > I am with David Gobbi and Ken. It would be a simple search and >> replace >> >> > once support for pre-C++11 compilers were dropped and the potential >> >> > for unintended consequences is too great. Glad to see there is >> general >> >> > support, I should have included more on my reasoning, but didn't want >> >> > to go into too much detail on implementation if there was little >> >> > support for it. >> >> > >> >> > It sounds like there is, nullptr is definitely another piece of low >> >> > hanging fruit. There is lots more that would be great to use, the >> >> > language is evolving and it is important that we take advantage of >> the >> >> > parts that make sense. >> >> > >> >> > Marcus >> >> > >> >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >> >> > wrote: >> >> >> Yes, I also believe that using "#define override" has the potential >> to >> >> >> cause problems. Let's say that "override" appears as a variable >> >> >> somewhere in code that someone brought into VTK and tested with a >> >> >> C++11 compiler (this is legal, since "override" is not a keyword). >> >> >> Then someone else tries compiling that code on C++03 where the >> >> >> "#define override" is active. All of a sudden, "override" is >> replaced >> >> >> by nothing anywhere it is used as a variable (or as any other kind >> of >> >> >> identifier). >> >> >> >> >> >> >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> >> >> wrote: >> >> >>> Hi Ken >> >> >>> >> >> >>> Good point, thanks for that. >> >> >>> >> >> >>> Andrew >> >> >>> >> >> >>> >> >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth < >> kmorel at sandia.gov> >> >> >>> wrote: >> >> >>>> >> >> >>>> +1 for me too. >> >> >>>> >> >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >> >> >>>> and >> >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >> >> >>>> disconcerting >> >> >>>> when libraries try to get cute with changing the behavior of (or >> >> >>>> trying to >> >> >>>> emulate) keywords with preprocessor macros. It can be pretty >> >> >>>> confusing when >> >> >>>> something goes wrong, and good luck if you have to use two >> separate >> >> >>>> projects >> >> >>>> together that both tried to define preprocessor macros with >> different >> >> >>>> implementations. >> >> >>>> >> >> >>>> -Ken >> >> >>>> >> >> >>>> >> >> >>>> From: Andrew Maclean >> >> >>>> Reply-To: "andrew.amaclean at gmail.com" >> >> >>>> Date: Monday, August 18, 2014 4:09 PM >> >> >>>> To: VTK Developers , "Marcus D. Hanwell" >> >> >>>> , Ben Boeckel < >> ben.boeckel at kitware.com>, >> >> >>>> Sean >> >> >>>> McBride >> >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) >> C++11 >> >> >>>> features in VTK >> >> >>>> >> >> >>>> +1! ... actually: ++1 :-) >> >> >>>> >> >> >>>> I would support this. To keep VTK relevant we need to be >> introducing >> >> >>>> these >> >> >>>> features. Especially features like nullptr, unique_ptr etc. >> >> >>>> >> >> >>>> But I would not be happy at introducing more VTK defines like >> >> >>>> VTK_OVERRIDE >> >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >> >> >>>> idea of >> >> >>>> using a modernise tool. >> >> >>>> >> >> >>>> Regards >> >> >>>> Andrew >> >> >>>> >> >> >>>> >> >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Marcus D. Hanwell" >> >> >>>>> To: VTK Developers >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features >> in >> >> >>>>> VTK >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>> As we move forward, it would be great to get a feeling for >> people's >> >> >>>>> thoughts about integrating some components of C++11 optionally. >> So >> >> >>>>> if >> >> >>>>> C++11 is available/enabled, there are several features we could >> >> >>>>> enable >> >> >>>>> optionally at compile time. >> >> >>>>> >> >> >>>>> A very simple example is that of the new override keyword, that >> is >> >> >>>>> used to indicate that a member function is overriding a virtual >> >> >>>>> function. Using this can avoid mistakes where the signature >> changes >> >> >>>>> and derived classes are missed. It can be defined in a header >> (empty >> >> >>>>> on old compilers, override with recent compilers). Final is >> similar, >> >> >>>>> indicating that the virtual function cannot be overridden in >> derived >> >> >>>>> classes. >> >> >>>>> >> >> >>>>> This would introduce changes to the VTK coding style, where we >> now >> >> >>>>> use >> >> >>>>> virtual for all virtual functions (first declaration, or >> subsequent >> >> >>>>> overrides). We could introduce this gradually for new code, even >> >> >>>>> having one or two dashboards compiling this way would help spot >> >> >>>>> simple >> >> >>>>> errors such as an incorrect signature not actually overriding a >> >> >>>>> function, but in fact declaring a new virtual for example. >> >> >>>>> >> >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use >> the >> >> >>>>> new keywords. >> >> >>>>> >> >> >>>>> Thoughts, objections? There are lots of other features, and I >> know >> >> >>>>> it >> >> >>>>> will be a while before we can use them all but it would be great >> to >> >> >>>>> make a start with some of the easier ones that can improve code >> >> >>>>> quality with little overhead. >> >> >>>>> >> >> >>>>> Marcus >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: Ben Boeckel >> >> >>>>> To: "Marcus D. Hanwell" >> >> >>>>> Cc: VTK Developers >> >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >> >>>>> > Thoughts, objections? There are lots of other features, and I >> know >> >> >>>>> > it >> >> >>>>> > will be a while before we can use them all but it would be >> great >> >> >>>>> > to >> >> >>>>> > make a start with some of the easier ones that can improve code >> >> >>>>> > quality with little overhead. >> >> >>>>> >> >> >>>>> What about "= delete" for removing default assignment and copy >> >> >>>>> constructors? >> >> >>>>> >> >> >>>>> --Ben >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Marcus D. Hanwell" >> >> >>>>> To: Ben Boeckel >> >> >>>>> Cc: VTK Developers >> >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell >> wrote: >> >> >>>>> >> Thoughts, objections? There are lots of other features, and I >> >> >>>>> >> know it >> >> >>>>> >> will be a while before we can use them all but it would be >> great >> >> >>>>> >> to >> >> >>>>> >> make a start with some of the easier ones that can improve >> code >> >> >>>>> >> quality with little overhead. >> >> >>>>> > >> >> >>>>> > What about "= delete" for removing default assignment and copy >> >> >>>>> > constructors? >> >> >>>>> > >> >> >>>>> Certainly, I think we should start out simple and then build it >> out. >> >> >>>>> If we have prototypes for a few of the most useful features that >> can >> >> >>>>> easily be encapsulated in compile time logic that will degrade to >> >> >>>>> C++98 that would be great. >> >> >>>>> >> >> >>>>> Marcus >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Sean McBride" >> >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >> >>>>> Developers" >> >> >>>>> >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >> >>>>> >> >> >>>>> >As we move forward, it would be great to get a feeling for >> people's >> >> >>>>> >thoughts about integrating some components of C++11 optionally. >> So >> >> >>>>> > if >> >> >>>>> >C++11 is available/enabled, there are several features we could >> >> >>>>> > enable >> >> >>>>> >optionally at compile time. >> >> >>>>> >> >> >>>>> +1 from me. >> >> >>>>> >> >> >>>>> nullptr is another one that can be made to work even on older >> >> >>>>> compilers >> >> >>>>> with some #define glue. >> >> >>>>> >> >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use >> 'override' >> >> >>>>> as if >> >> >>>>> we required C++11 and "#define override /* nothing */" as >> >> >>>>> appropriate. Then >> >> >>>>> when C++11 really is the minimun requirement no big find/replace >> is >> >> >>>>> required. Just a thought. >> >> >>>>> >> >> >>>>> PS: I already have dashboards building as C++11 and C++14. >> >> >>>>> >> >> >>>>> Cheers, >> >> >>>>> >> >> >>>>> -- >> >> >>>>> ____________________________________________________________ >> >> >>>>> Sean McBride, B. Eng sean at rogue-research.com >> >> >>>>> Rogue Research www.rogue-research.com >> >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Sean McBride" >> >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >> >>>>> Developers" >> >> >>>>> >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >> >>>>> >> >> >>>>> >nullptr is another one that can be made to work even on older >> >> >>>>> > compilers >> >> >>>>> >with some #define glue. >> >> >>>>> > >> >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use >> 'override' >> >> >>>>> > as if >> >> >>>>> >we required C++11 and "#define override /* nothing */" as >> >> >>>>> > appropriate. >> >> >>>>> >Then when C++11 really is the minimun requirement no big >> >> >>>>> > find/replace is >> >> >>>>> >required. Just a thought. >> >> >>>>> >> >> >>>>> I hit send too fast... >> >> >>>>> >> >> >>>>> I also wanted to suggest looking at the clang-modernize tool, >> which >> >> >>>>> is "a >> >> >>>>> standalone tool used to automatically convert C++ code written >> >> >>>>> against old >> >> >>>>> standards to use features of the newest C++ standard". >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> Specifically, it can be used to automatically add 'override' and >> >> >>>>> convert >> >> >>>>> to 'nullptr': >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> Cheers, >> >> >> _______________________________________________ >> >> >> Powered by www.kitware.com >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> 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 >> >> > >> >> > Follow this link to subscribe/unsubscribe: >> >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > >> > >> > >> > >> > >> > -- >> > ___________________________________________ >> > Andrew J. P. Maclean >> > >> > ___________________________________________ >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > -- > +1 919 869 8849 > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Aug 21 09:20:54 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Aug 2014 09:20:54 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <53F5F236.7030705@kitware.com> On 08/20/2014 06:39 PM, Andrew Maclean wrote: > To help the process along I did a cursory search and found these links: > > C++11 Detection with CMake: http://pageant.ghulbus.eu/?p=664 > > And down in the notes there is a comment from Rolf Eike Beer: > > I have pushed a repository for this module online. I have incorporated some of your changes, especially the 3 new tests. > > git clone git://anongit.kde.org/scratch/dakon/cmake-cxx11 > > This could make a really good basis for the C++11 implementation. > I checked out the repository and it seems to work, read CheckCX11features.cmake > it creates lots of variables called HAS_CXX11_* e.g. HAS_CXX11_LAMBDA That work was originally proposed for inclusion in CMake, but it has been superseded by new builtin features in post-3.0 development. See the new cmake-compile-features(7) manual: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-compile-features.7.rst;hb=4517d6b7 the target_compile_features command: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/command/target_compile_features.rst;hb=4517d6b7 and the WriteCompilerDetectionHeader module: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/WriteCompilerDetectionHeader.cmake;hb=4517d6b7 Of course these won't be available until CMake 3.1 and still require someone to fill in feature tables for MSVC (currently only GCC and Clang are supported). -Brad From marcus.hanwell at kitware.com Fri Aug 22 11:57:56 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 22 Aug 2014 11:57:56 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: So my first pass at this, keeping the bar relatively low for now, http://review.source.kitware.com/#/t/4550/ I have tested this both as default, and forcing to ANSI C++, on GCC 4.9.1. It would be pretty simple to extend this for Clang (I would rather do it in a follow up commit). This does change the default to enable C++11 if the GCC compiler reports it is capable of this, and I verified the VTK_OVERRIDE fails as expected when overriding something that is not virtual. When looking at this it raised the question (for me at least) of whether we ask for ANSI C++, and the standards (I think we should), or the GNU specific extensions (what we were implicitly doing before by passing nothing unless extra warnings were turned on). The features coming up in CMake look great, but I don't think we need to wait in order to use some of the simpler features. It passes on the Gerrit submissions, so nothing terrible happened on the surface, I think this set is pretty conservative. Let me know if you see major issues in the approach, you can see in a single class (vtkBitArray) how VTK_OVERRIDE and VTK_NULLPTR are used. Marcus On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell wrote: > Yes, and there are more extensive examples in the Qt project (for 5+), > and Boost where they both used the prefixed macro name approach. I can > get some of the basics in pretty quickly as I haven't heard much > opposition. > > Marcus > > On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean > wrote: >> Brilliant! It looks as if ITK has already done a lot of this! >> >> >> Andrew >> >> >> >> On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick >> wrote: >>> >>> VTK_OVERRIDE would be nice, and it would be nice to macros that are >>> similar to ITK. Currently there is >>> >>> ITK_OVERRIDE >>> ITK_NOEXCEPT >>> ITK_NULLPTR >>> >>> >>> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >>> >>> >>> Thanks, >>> Matt >>> >>> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >>> wrote: >>> > I am with David Gobbi and Ken. It would be a simple search and replace >>> > once support for pre-C++11 compilers were dropped and the potential >>> > for unintended consequences is too great. Glad to see there is general >>> > support, I should have included more on my reasoning, but didn't want >>> > to go into too much detail on implementation if there was little >>> > support for it. >>> > >>> > It sounds like there is, nullptr is definitely another piece of low >>> > hanging fruit. There is lots more that would be great to use, the >>> > language is evolving and it is important that we take advantage of the >>> > parts that make sense. >>> > >>> > Marcus >>> > >>> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >>> > wrote: >>> >> Yes, I also believe that using "#define override" has the potential to >>> >> cause problems. Let's say that "override" appears as a variable >>> >> somewhere in code that someone brought into VTK and tested with a >>> >> C++11 compiler (this is legal, since "override" is not a keyword). >>> >> Then someone else tries compiling that code on C++03 where the >>> >> "#define override" is active. All of a sudden, "override" is replaced >>> >> by nothing anywhere it is used as a variable (or as any other kind of >>> >> identifier). >>> >> >>> >> >>> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >>> >> wrote: >>> >>> Hi Ken >>> >>> >>> >>> Good point, thanks for that. >>> >>> >>> >>> Andrew >>> >>> >>> >>> >>> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >>> >>> wrote: >>> >>>> >>> >>>> +1 for me too. >>> >>>> >>> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >>> >>>> and >>> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >>> >>>> disconcerting >>> >>>> when libraries try to get cute with changing the behavior of (or >>> >>>> trying to >>> >>>> emulate) keywords with preprocessor macros. It can be pretty >>> >>>> confusing when >>> >>>> something goes wrong, and good luck if you have to use two separate >>> >>>> projects >>> >>>> together that both tried to define preprocessor macros with different >>> >>>> implementations. >>> >>>> >>> >>>> -Ken >>> >>>> >>> >>>> >>> >>>> From: Andrew Maclean >>> >>>> Reply-To: "andrew.amaclean at gmail.com" >>> >>>> Date: Monday, August 18, 2014 4:09 PM >>> >>>> To: VTK Developers , "Marcus D. Hanwell" >>> >>>> , Ben Boeckel , >>> >>>> Sean >>> >>>> McBride >>> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>> >>>> features in VTK >>> >>>> >>> >>>> +1! ... actually: ++1 :-) >>> >>>> >>> >>>> I would support this. To keep VTK relevant we need to be introducing >>> >>>> these >>> >>>> features. Especially features like nullptr, unique_ptr etc. >>> >>>> >>> >>>> But I would not be happy at introducing more VTK defines like >>> >>>> VTK_OVERRIDE >>> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >>> >>>> idea of >>> >>>> using a modernise tool. >>> >>>> >>> >>>> Regards >>> >>>> Andrew >>> >>>> >>> >>>> >>> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >>> >>>> wrote: >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Marcus D. Hanwell" >>> >>>>> To: VTK Developers >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in >>> >>>>> VTK >>> >>>>> Hi, >>> >>>>> >>> >>>>> As we move forward, it would be great to get a feeling for people's >>> >>>>> thoughts about integrating some components of C++11 optionally. So >>> >>>>> if >>> >>>>> C++11 is available/enabled, there are several features we could >>> >>>>> enable >>> >>>>> optionally at compile time. >>> >>>>> >>> >>>>> A very simple example is that of the new override keyword, that is >>> >>>>> used to indicate that a member function is overriding a virtual >>> >>>>> function. Using this can avoid mistakes where the signature changes >>> >>>>> and derived classes are missed. It can be defined in a header (empty >>> >>>>> on old compilers, override with recent compilers). Final is similar, >>> >>>>> indicating that the virtual function cannot be overridden in derived >>> >>>>> classes. >>> >>>>> >>> >>>>> This would introduce changes to the VTK coding style, where we now >>> >>>>> use >>> >>>>> virtual for all virtual functions (first declaration, or subsequent >>> >>>>> overrides). We could introduce this gradually for new code, even >>> >>>>> having one or two dashboards compiling this way would help spot >>> >>>>> simple >>> >>>>> errors such as an incorrect signature not actually overriding a >>> >>>>> function, but in fact declaring a new virtual for example. >>> >>>>> >>> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>> >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >>> >>>>> new keywords. >>> >>>>> >>> >>>>> Thoughts, objections? There are lots of other features, and I know >>> >>>>> it >>> >>>>> will be a while before we can use them all but it would be great to >>> >>>>> make a start with some of the easier ones that can improve code >>> >>>>> quality with little overhead. >>> >>>>> >>> >>>>> Marcus >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: Ben Boeckel >>> >>>>> To: "Marcus D. Hanwell" >>> >>>>> Cc: VTK Developers >>> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >>>>> > Thoughts, objections? There are lots of other features, and I know >>> >>>>> > it >>> >>>>> > will be a while before we can use them all but it would be great >>> >>>>> > to >>> >>>>> > make a start with some of the easier ones that can improve code >>> >>>>> > quality with little overhead. >>> >>>>> >>> >>>>> What about "= delete" for removing default assignment and copy >>> >>>>> constructors? >>> >>>>> >>> >>>>> --Ben >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Marcus D. Hanwell" >>> >>>>> To: Ben Boeckel >>> >>>>> Cc: VTK Developers >>> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>> >>>>> >>> >>>>> wrote: >>> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >>>>> >> Thoughts, objections? There are lots of other features, and I >>> >>>>> >> know it >>> >>>>> >> will be a while before we can use them all but it would be great >>> >>>>> >> to >>> >>>>> >> make a start with some of the easier ones that can improve code >>> >>>>> >> quality with little overhead. >>> >>>>> > >>> >>>>> > What about "= delete" for removing default assignment and copy >>> >>>>> > constructors? >>> >>>>> > >>> >>>>> Certainly, I think we should start out simple and then build it out. >>> >>>>> If we have prototypes for a few of the most useful features that can >>> >>>>> easily be encapsulated in compile time logic that will degrade to >>> >>>>> C++98 that would be great. >>> >>>>> >>> >>>>> Marcus >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Sean McBride" >>> >>>>> To: "Marcus D. Hanwell" , "VTK >>> >>>>> Developers" >>> >>>>> >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>> >>>>> >>> >>>>> >As we move forward, it would be great to get a feeling for people's >>> >>>>> >thoughts about integrating some components of C++11 optionally. So >>> >>>>> > if >>> >>>>> >C++11 is available/enabled, there are several features we could >>> >>>>> > enable >>> >>>>> >optionally at compile time. >>> >>>>> >>> >>>>> +1 from me. >>> >>>>> >>> >>>>> nullptr is another one that can be made to work even on older >>> >>>>> compilers >>> >>>>> with some #define glue. >>> >>>>> >>> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >>> >>>>> as if >>> >>>>> we required C++11 and "#define override /* nothing */" as >>> >>>>> appropriate. Then >>> >>>>> when C++11 really is the minimun requirement no big find/replace is >>> >>>>> required. Just a thought. >>> >>>>> >>> >>>>> PS: I already have dashboards building as C++11 and C++14. >>> >>>>> >>> >>>>> Cheers, >>> >>>>> >>> >>>>> -- >>> >>>>> ____________________________________________________________ >>> >>>>> Sean McBride, B. Eng sean at rogue-research.com >>> >>>>> Rogue Research www.rogue-research.com >>> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Sean McBride" >>> >>>>> To: "Marcus D. Hanwell" , "VTK >>> >>>>> Developers" >>> >>>>> >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>> >>>>> >>> >>>>> >nullptr is another one that can be made to work even on older >>> >>>>> > compilers >>> >>>>> >with some #define glue. >>> >>>>> > >>> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >>> >>>>> > as if >>> >>>>> >we required C++11 and "#define override /* nothing */" as >>> >>>>> > appropriate. >>> >>>>> >Then when C++11 really is the minimun requirement no big >>> >>>>> > find/replace is >>> >>>>> >required. Just a thought. >>> >>>>> >>> >>>>> I hit send too fast... >>> >>>>> >>> >>>>> I also wanted to suggest looking at the clang-modernize tool, which >>> >>>>> is "a >>> >>>>> standalone tool used to automatically convert C++ code written >>> >>>>> against old >>> >>>>> standards to use features of the newest C++ standard". >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Specifically, it can be used to automatically add 'override' and >>> >>>>> convert >>> >>>>> to 'nullptr': >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Cheers, >>> >> _______________________________________________ >>> >> Powered by www.kitware.com >>> >> >>> >> Visit other Kitware open-source projects at >>> >> http://www.kitware.com/opensource/opensource.html >>> >> >>> >> 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 >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ From sean at rogue-research.com Fri Aug 22 13:15:39 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 13:15:39 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140822171539.406274357@mail.rogue-research.com> Marcus, First, thanks for working on this! I realize you are just testing things out, but some comments nonetheless: On Fri, 22 Aug 2014 11:57:56 -0400, Marcus D. Hanwell said: >So my first pass at this, keeping the bar relatively low for now, > >http://review.source.kitware.com/#/t/4550/ > >I have tested this both as default, and forcing to ANSI C++, on GCC >4.9.1. It would be pretty simple to extend this for Clang (I would >rather do it in a follow up commit). I think the term "ANSI C++" is horribly ambiguous, and shouldn't be used (ex: VTK_FORCE_ANSI_CXX). Honestly, I'm not even sure what you mean by it. Do you mean C++98? The string "ANSI" doesn't even appear on the wikipedia C++ page: :) Better to use these names IMNSHO: >This does change the default to >enable C++11 if the GCC compiler reports it is capable of this I would argue against forcing any particular dialect. It seems to me that that should be an explicit choice made by the user at compile time. Specially since VTK is a library. If my app is built as C++98 and VTK 6.2 suddenly decides to build itself as C++11 then I could easily get freaky link errors because of changes to mangling, etc. >verified the VTK_OVERRIDE fails as expected when overriding something >that is not virtual. When looking at this it raised the question (for >me at least) of whether we ask for ANSI C++, and the standards (I >think we should), or the GNU specific extensions (what we were >implicitly doing before by passing nothing unless extra warnings were >turned on). As VTK is cross platform, best to use as few gcc extensions as possible, none ideally. clang has a warning that warns when gcc extensions are used, as I recall there are a few in the VTK codebase, like using C99 VLAs in C++ files. I'll do a build and see how many warnings pop... >The features coming up in CMake look great, but I don't think we need >to wait in order to use some of the simpler features. Agreed. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Fri Aug 22 13:25:54 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 22 Aug 2014 13:25:54 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140822171539.406274357@mail.rogue-research.com> References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: On Fri, Aug 22, 2014 at 1:15 PM, Sean McBride wrote: > Marcus, > > First, thanks for working on this! > > I realize you are just testing things out, but some comments nonetheless: > > > On Fri, 22 Aug 2014 11:57:56 -0400, Marcus D. Hanwell said: > >>So my first pass at this, keeping the bar relatively low for now, >> >>http://review.source.kitware.com/#/t/4550/ >> >>I have tested this both as default, and forcing to ANSI C++, on GCC >>4.9.1. It would be pretty simple to extend this for Clang (I would >>rather do it in a follow up commit). > > I think the term "ANSI C++" is horribly ambiguous, and shouldn't be used (ex: VTK_FORCE_ANSI_CXX). Honestly, I'm not even sure what you mean by it. Do you mean C++98? > > The string "ANSI" doesn't even appear on the wikipedia C++ page: :) > Wikipedia isn't the only source of information, http://www.cplusplus.com/info/faq/ talks about it, and http://gcc.gnu.org/onlinedocs/gcc/Standards.html discusses the -ansi flag, versus the -std=blah. I am not particularly tied to it, but it is fairly widely used. > > Better to use these names IMNSHO: > > >>This does change the default to >>enable C++11 if the GCC compiler reports it is capable of this > > I would argue against forcing any particular dialect. It seems to me that that should be an explicit choice made by the user at compile time. Specially since VTK is a library. If my app is built as C++98 and VTK 6.2 suddenly decides to build itself as C++11 then I could easily get freaky link errors because of changes to mangling, etc. This is where I was less certain, although I am not aware of changes in mangling for stuff we care about - do you have examples here, or just being cautious? As far as I know the MSVC compilers enable all new C++ features by default, whereas GCC/Clang need it to be enabled. > >>verified the VTK_OVERRIDE fails as expected when overriding something >>that is not virtual. When looking at this it raised the question (for >>me at least) of whether we ask for ANSI C++, and the standards (I >>think we should), or the GNU specific extensions (what we were >>implicitly doing before by passing nothing unless extra warnings were >>turned on). > > As VTK is cross platform, best to use as few gcc extensions as possible, none ideally. > > clang has a warning that warns when gcc extensions are used, as I recall there are a few in the VTK codebase, like using C99 VLAs in C++ files. I'll do a build and see how many warnings pop... I doubt we have many, as we normally make people fix these in review and they cause failures on Windows for example. I guess we can go with explicitly enabling, but at some point we may want to change this to the other way around. Otherwise you end up with a bunch of features most developers/users never see/enable as they are not aware of all the flags. Maybe we want a meta flag for VTK - enable new stuff, as GCC visibility is off by default, extra compiler warnings, possibly now new C++ features, and it is quite a list to enable one-by-one. We can take some time to mull it over, but I personally wouldn't mind the enable all new features flag grouping. Marcus From sean at rogue-research.com Fri Aug 22 13:58:43 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 13:58:43 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: <20140822175843.864531183@mail.rogue-research.com> On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: >Wikipedia isn't the only source of information, >http://www.cplusplus.com/info/faq/ talks about it, and >http://gcc.gnu.org/onlinedocs/gcc/Standards.html discusses the -ansi >flag, versus the -std=blah. I am not particularly tied to it, but it >is fairly widely used. It can of course be widely used and ambiguous at the same time. :) It's similarly ambiguous to refer to "ISO C", as there have been several over the years. 4th google result for "ANSI C++": I think saying "C++98" (or "ISO C++98") is unarguably clearer than saying "ANSI C++". >This is where I was less certain, although I am not aware of changes >in mangling for stuff we care about - do you have examples here, or >just being cautious? The latter. "The C++98 language is ABI-compatible with the C++11 language, but several places in the library break compatibility. This makes it dangerous to link C++98 objects with C++11 objects." 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 sean at rogue-research.com Fri Aug 22 17:21:42 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 17:21:42 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: <20140822212142.260638657@mail.rogue-research.com> On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: >> clang has a warning that warns when gcc extensions are used, as I >recall there are a few in the VTK codebase, like using C99 VLAs in C++ >files. I'll do a build and see how many warnings pop... > >I doubt we have many, as we normally make people fix these in review >and they cause failures on Windows for example. So I built with clang and "-std=c++11 -stdlib=libc++ -pedantic -Wno-extra-semi" and there were only a few warnings: a) 15 of the form: VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2568:5: warning: variable length arrays are a C99 feature [-Wvla-extension] ALLOC_LOCAL_ARRAY( derivatives, REAL2, nv-1 ); ^ VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2201:49: note: expanded from macro 'ALLOC_LOCAL_ARRAY' #define ALLOC_LOCAL_ARRAY(name,type,n) type name[(n)] ^ This works in Windows as there is a malloc fallback case. b) 3 of the form: VTK/Rendering/Label/vtkLabelHierarchy.cxx:887:10: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion] if ( &(this->Node->value()) ) ~~ ~^~~~~~~~~~~~~~~~~~~~ VTK/Utilities/octree/octree_node.h:48:13: note: 'value' returns a reference reference value() { return this->_M_data; } ^ 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 andrew.amaclean at gmail.com Sat Aug 23 02:35:02 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sat, 23 Aug 2014 16:35:02 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140822212142.260638657@mail.rogue-research.com> References: <20140822171539.406274357@mail.rogue-research.com> <20140822212142.260638657@mail.rogue-research.com> Message-ID: Just did a bit of digging around in the Microsoft documentation and it seems VS2012 and VS2013 support final, override and nullptr. There is a lot of info and tables here: http://msdn.microsoft.com/en-us/library/hh567368.aspx final: VS2012/2013 overrride: VS2012/2013 nullptr VS2010/2013 So you can probably allow their use for these compilers in VTK. Probably somewhere in vtkCompilerExtras.cmake and vtkWin32Header.h. Actually there is CMAKE_CXX_COMPILER_ID, CMAKE_CXX_COMPILER_VERSION available but I am not sure it was accessible in cmake 2.8.8 (the minimum for VTK). For VS2013 I get Compiler ID/Version: MSVC 18.0.30723.0 (however I am using CMake 3.1). CMAKE_CXX_COMPILER_ID returns at least one of "GNU", "MSVC", "Clang". Andrew Andrew Andrew On Sat, Aug 23, 2014 at 7:21 AM, Sean McBride wrote: > On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: > > >> clang has a warning that warns when gcc extensions are used, as I > >recall there are a few in the VTK codebase, like using C99 VLAs in C++ > >files. I'll do a build and see how many warnings pop... > > > >I doubt we have many, as we normally make people fix these in review > >and they cause failures on Windows for example. > > So I built with clang and "-std=c++11 -stdlib=libc++ -pedantic > -Wno-extra-semi" and there were only a few warnings: > > a) 15 of the form: > > VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2568:5: warning: > variable length arrays are a C99 feature [-Wvla-extension] > ALLOC_LOCAL_ARRAY( derivatives, REAL2, nv-1 ); > ^ > VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2201:49: note: expanded > from macro 'ALLOC_LOCAL_ARRAY' > #define ALLOC_LOCAL_ARRAY(name,type,n) type name[(n)] > ^ > > This works in Windows as there is a malloc fallback case. > > > > b) 3 of the form: > > VTK/Rendering/Label/vtkLabelHierarchy.cxx:887:10: warning: reference > cannot be bound to dereferenced null pointer in well-defined C++ code; > pointer may be assumed to always convert to true > [-Wundefined-bool-conversion] > if ( &(this->Node->value()) ) > ~~ ~^~~~~~~~~~~~~~~~~~~~ > VTK/Utilities/octree/octree_node.h:48:13: note: 'value' returns a reference > reference value() { return this->_M_data; } > ^ > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Sat Aug 23 16:25:02 2014 From: julien.finet at kitware.com (Julien Finet) Date: Sat, 23 Aug 2014 16:25:02 -0400 Subject: [vtk-developers] When calling vtkWidgetRepresentation::BuildRepresentation() ? Message-ID: Hi, Short story: When should BuildRepresentation() be called ? Long story: I was facing a rendering issue with vtkOrientedPolygonalHandleRepresentation3D. The handle was not being rendered until I moved the camera to a special orientation. The issue was that the widget representation actor was being culled by the renderer which prevented any rendering from happening. And only a rendering (e.g. RenderOpaqueGeometry()) could update the actor position via BuildRepresentation(). Browsing through the code, it seems that it is being called at different places: a) when a display property is being called (e.g. vtkSplineRepresentation::SetClosed) b) when bounds are being called (e.g. vtkLineRepresentation::GetBounds()) c) after widgetInteraction is called (e.g. vtkBorderRepresentation::WidgetInteraction() d) when rendering is being called (e.g. vtkProp3DButtonRepresentation:: RenderOpaqueGeometry()) e) By the widget (e.g. vtkSliderWidget::AnimateSlider(), vtkAngleWidget::MoveAction()). It seems to be at the same time than c) Did I miss something ? Here are critics against each solution: a) seems a bit against the idea that BuildRepresentation() compresses all the Modified() events and creates/refresh the representation when all the changes are done. b) Do we know for sure GetBounds() is being called by the renderer before displaying any vtkProp ? c) What if the representation has no interaction ? (processing of events being OFF) d) As explained in my long story, it is too late to refresh the representation. (Rendering may never be called if the representation is not built') e) Same as d) Do you disagree with my critics ? Did I forget anything obvious ? It seems that b) (in GetBounds()) is the only valid location. Would you agree ? Thanks for those who read through my long email :-) Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 19:58:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 19:58:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: Hi folks, It is time for us to look at our options to replace our current Gerrit instance (review.source.kitware.com). Here is some background information: review.source.kitware.com runs a fork of the Gerrit code base from quite a while ago. The main feature of the fork is the support for topics (branches). The original Gerrit only supports reviewing of individual commits (changes) and has no concept of branches. The lack of support for branches is an issue for us from both automated testing and review point of view. So we extended Gerrit to support branches. Alas, our changes have not been accepted upstream and we are not interested in putting more effort in maintaining the fork as Gerrit code advances. So we can not make use of new Gerrit features and more importantly security fixes. So it is time to move on. I would like to start this process with a discussion of workflows (rather than tools). Let's first figure out one or more ideal (and reasonable) workflows. Then we can discuss tools to achieve these workflows and make a decision. Here I'll list some requirements that I thought are important in no particular order: - Maintain an open and "democratic" review process, a la Gerrit voting support. - The workflow needs to be distributed and not require a single (or a few) maintainer to integrate code. A la our Gerrit's review and merge support. - Workflow needs to scale with the community size. - Support for cdash @ home style testing of code under review before integration. - Support for arbitrary server side checks beyond cdash @ home before integration. - Support for "audit trail". There needs to be way of getting to the original discussion and reviews that led to the acceptance of a particular branch. I will follow up with a few initial workflow suggestions. Please send your workflow suggestions or requirements. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:04:34 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:04:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: Github / Bitbucket / Gitlab style workflow: This workflow is based on pull requests. A process through which anyone with an account can request a particular branch be merged to the original repository. There is usually support for discussion of individual pull requests and possibly support for approving of requests by community members (Bitbucket for example). This workflow supports branches with arbitrary numbers of commits. Diffs for the whole branch and individual commits are provided. The discussion usually happens around the diff of the whole branch. This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool. On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci wrote: > Hi folks, > > It is time for us to look at our options to replace our current Gerrit > instance (review.source.kitware.com). > > Here is some background information: review.source.kitware.com runs a > fork of the Gerrit code base from quite a while ago. The main feature of > the fork is the support for topics (branches). The original Gerrit only > supports reviewing of individual commits (changes) and has no concept of > branches. The lack of support for branches is an issue for us from both > automated testing and review point of view. So we extended Gerrit to > support branches. Alas, our changes have not been accepted upstream and we > are not interested in putting more effort in maintaining the fork as Gerrit > code advances. So we can not make use of new Gerrit features and more > importantly security fixes. So it is time to move on. > > I would like to start this process with a discussion of workflows (rather > than tools). Let's first figure out one or more ideal (and reasonable) > workflows. Then we can discuss tools to achieve these workflows and make a > decision. > > Here I'll list some requirements that I thought are important in no > particular order: > > - Maintain an open and "democratic" review process, a la Gerrit voting > support. > > - The workflow needs to be distributed and not require a single (or a few) > maintainer to integrate code. A la our Gerrit's review and merge support. > > - Workflow needs to scale with the community size. > > - Support for cdash @ home style testing of code under review before > integration. > > - Support for arbitrary server side checks beyond cdash @ home before > integration. > > - Support for "audit trail". There needs to be way of getting to the > original discussion and reviews that led to the acceptance of a particular > branch. > > I will follow up with a few initial workflow suggestions. Please send your > workflow suggestions or requirements. > > Best, > -berk > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:07:30 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:07:30 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: Vanilla Gerrit workflow: This workflow is based on reviewing individual commits. Merging also happens at individual commit level. Discussions and voting happen per commit. This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool. On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci wrote: > Github / Bitbucket / Gitlab style workflow: > > This workflow is based on pull requests. A process through which anyone > with an account can request a particular branch be merged to the original > repository. There is usually support for discussion of individual pull > requests and possibly support for approving of requests by community > members (Bitbucket for example). This workflow supports branches with > arbitrary numbers of commits. Diffs for the whole branch and individual > commits are provided. The discussion usually happens around the diff of the > whole branch. > > This workflow is almost entirely driven by a Web interface. Discussions > happen almost entirely in the Web tool. > > > On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci > wrote: > >> Hi folks, >> >> It is time for us to look at our options to replace our current Gerrit >> instance (review.source.kitware.com). >> >> Here is some background information: review.source.kitware.com runs a >> fork of the Gerrit code base from quite a while ago. The main feature of >> the fork is the support for topics (branches). The original Gerrit only >> supports reviewing of individual commits (changes) and has no concept of >> branches. The lack of support for branches is an issue for us from both >> automated testing and review point of view. So we extended Gerrit to >> support branches. Alas, our changes have not been accepted upstream and we >> are not interested in putting more effort in maintaining the fork as Gerrit >> code advances. So we can not make use of new Gerrit features and more >> importantly security fixes. So it is time to move on. >> >> I would like to start this process with a discussion of workflows (rather >> than tools). Let's first figure out one or more ideal (and reasonable) >> workflows. Then we can discuss tools to achieve these workflows and make a >> decision. >> >> Here I'll list some requirements that I thought are important in no >> particular order: >> >> - Maintain an open and "democratic" review process, a la Gerrit voting >> support. >> >> - The workflow needs to be distributed and not require a single (or a >> few) maintainer to integrate code. A la our Gerrit's review and merge >> support. >> >> - Workflow needs to scale with the community size. >> >> - Support for cdash @ home style testing of code under review before >> integration. >> >> - Support for arbitrary server side checks beyond cdash @ home before >> integration. >> >> - Support for "audit trail". There needs to be way of getting to the >> original discussion and reviews that led to the acceptance of a particular >> branch. >> >> I will follow up with a few initial workflow suggestions. Please send >> your workflow suggestions or requirements. >> >> Best, >> -berk >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:13:27 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:13:27 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: E-mail workflow (similar to Linux kernel): In this workflow, discussions on commits/branches happen on the mailing list. This workflow could be augmented by Web tools such as Github and Gist. However, merge requests and discussions happen on the mailing list. On Sat, Aug 23, 2014 at 8:07 PM, Berk Geveci wrote: > Vanilla Gerrit workflow: > > This workflow is based on reviewing individual commits. Merging also > happens at individual commit level. Discussions and voting happen per > commit. > > This workflow is almost entirely driven by a Web interface. Discussions > happen almost entirely in the Web tool. > > > On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci > wrote: > >> Github / Bitbucket / Gitlab style workflow: >> >> This workflow is based on pull requests. A process through which anyone >> with an account can request a particular branch be merged to the original >> repository. There is usually support for discussion of individual pull >> requests and possibly support for approving of requests by community >> members (Bitbucket for example). This workflow supports branches with >> arbitrary numbers of commits. Diffs for the whole branch and individual >> commits are provided. The discussion usually happens around the diff of the >> whole branch. >> >> This workflow is almost entirely driven by a Web interface. Discussions >> happen almost entirely in the Web tool. >> >> >> On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci >> wrote: >> >>> Hi folks, >>> >>> It is time for us to look at our options to replace our current Gerrit >>> instance (review.source.kitware.com). >>> >>> Here is some background information: review.source.kitware.com runs a >>> fork of the Gerrit code base from quite a while ago. The main feature of >>> the fork is the support for topics (branches). The original Gerrit only >>> supports reviewing of individual commits (changes) and has no concept of >>> branches. The lack of support for branches is an issue for us from both >>> automated testing and review point of view. So we extended Gerrit to >>> support branches. Alas, our changes have not been accepted upstream and we >>> are not interested in putting more effort in maintaining the fork as Gerrit >>> code advances. So we can not make use of new Gerrit features and more >>> importantly security fixes. So it is time to move on. >>> >>> I would like to start this process with a discussion of workflows >>> (rather than tools). Let's first figure out one or more ideal (and >>> reasonable) workflows. Then we can discuss tools to achieve these workflows >>> and make a decision. >>> >>> Here I'll list some requirements that I thought are important in no >>> particular order: >>> >>> - Maintain an open and "democratic" review process, a la Gerrit voting >>> support. >>> >>> - The workflow needs to be distributed and not require a single (or a >>> few) maintainer to integrate code. A la our Gerrit's review and merge >>> support. >>> >>> - Workflow needs to scale with the community size. >>> >>> - Support for cdash @ home style testing of code under review before >>> integration. >>> >>> - Support for arbitrary server side checks beyond cdash @ home before >>> integration. >>> >>> - Support for "audit trail". There needs to be way of getting to the >>> original discussion and reviews that led to the acceptance of a particular >>> branch. >>> >>> I will follow up with a few initial workflow suggestions. Please send >>> your workflow suggestions or requirements. >>> >>> Best, >>> -berk >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Aug 23 21:04:32 2014 From: david.thompson at kitware.com (David Thompson) Date: Sat, 23 Aug 2014 21:04:32 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Hi Berk, > It is time for us to look at our options to replace our current Gerrit instance (review.source.kitware.com). ... > Here I'll list some requirements that I thought are important in no particular order: > - Maintain an open and "democratic" review process, a la Gerrit voting support. +1 > - The workflow needs to be distributed and not require a single (or a few) maintainer to integrate code. A la our Gerrit's review and merge support. Distributed is great. But it also helps to have stakeholders for particular pieces of code, especially for core functionality, whose buy-off (or at least notification) is required. > - Support for cdash @ home style testing of code under review before integration. +1 > - Support for arbitrary server side checks beyond cdash @ home before integration. As long as arbitrary does not become whimsical. For instance, whitespace rules make it very un-fun to keep third-party libraries up to date in VTK; when a library like netcdf or exodus does not have strict rules about trailing whitespace, merging in a new release from upstream is tedious. > - Support for "audit trail". There needs to be way of getting to the original discussion and reviews that led to the acceptance of a particular branch. +1 Also, it should be easy to find the audit trail starting with a git hash. > I will follow up with a few initial workflow suggestions. Please send your workflow suggestions or requirements. Suggestions: - It takes a long time for tests to run because VTK is large. Often, changes to non-core functionality run a lot of unnecessary, unrelated tests. It would be nice to have submitters and/or reviewers force a few tests by name and let the review system choose other tests to run using some static analysis to find tests that have a chance of executing the updated code. Since CDash tracks average test time, it would be easy to have a time budget for choosing tests. - It would be nice to have tighter integration with the release process and issue tracking so that reports of features added and bugs fixed could be generated. I think what we do of that is mostly by hand now, isn't it? Suggested Requirements:-) - Review system comments should be Markdown or rST or something easily presented as HTML which can include links -- at least to the VTK wiki and bug tracker, if nothing else. It would be really nice if pull requests could effectively become parts of a wiki page or blog so that we could curate user-guide-style documentation instead of just doxygen reference docs. Not that every topic would have to become part of a user's guide, but it should be easy to pull topic info into a user's guide. - An anti-requirement: Less e-mail spam when (1) a topic includes multiple commits and/or (2) automated testing completes. For instance, I can think of one topic I'm a reviewer on that has 40-something commits. There are 16 changesets and reviewers get 1 per commit per changeset-the-commit-is-modified. 2?, David From david.gobbi at gmail.com Sat Aug 23 22:18:11 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 23 Aug 2014 20:18:11 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I'm all for sticking with gerrit. I'll be sad to lose the topic review interface, but topics in vanilla gerrit really aren't that bad. We'll still be able to push topics and we'll be able to see all the changes that make up a topic. I believe that what we lose is 1) the ability to do a topic-level review and 2) the ability to browse by topic. The only thing that annoys me with gerrit is that when you click "review", it hides all of the previous review comments until you're done. Hopefully the new gerrit has fixed this. The things I'd like to see in a code review system are: - Tight integration with the bugtracker. - Some kind of incentive for reviewers, even if it's just gold stars or a "top reviewer" list. Or we could be draconian and enforce a review/submit ratio, just like the old BBS's enforced upload/download ratios. - David From david.thompson at kitware.com Sat Aug 23 22:25:02 2014 From: david.thompson at kitware.com (David Thompson) Date: Sat, 23 Aug 2014 22:25:02 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> > ... The only thing that annoys me with gerrit is that when you click > "review", it hides all of the previous review comments until you're > done. ... This reminds me of another Gerrit annoyance: it is very difficult to get Gerrit to show you the difference between changeset revisions. I forget whether it happens at the topic or the changeset level, but Gerrit has a bug that prevents this kind of diff. If someone uploads a new revision of a topic it is important to be able to see the diffs to the previous revision, not just the branch point. David From david.gobbi at gmail.com Sat Aug 23 23:17:25 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 23 Aug 2014 21:17:25 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> Message-ID: On Sat, Aug 23, 2014 at 8:25 PM, David Thompson wrote: > This reminds me of another Gerrit annoyance: it is very difficult > to get Gerrit to show you the difference between changeset > revisions. I forget whether it happens at the topic or the changeset > level, but Gerrit has a bug that prevents this kind of diff. If someone > uploads a new revision of a topic it is important to be able to see > the diffs to the previous revision, not just the branch point. This problem occurs at the changeset level whenever the topic is rebased. Submitters should avoid gratuitous rebasing. - David From berk.geveci at kitware.com Sun Aug 24 08:37:43 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sun, 24 Aug 2014 08:37:43 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Hi David, >From what I can tell, you can't even get the order of changesets in a topic in vanilla Gerrit. You can search by a topic but that seems to be it for topic support. Also, I don't think that there is any way of merging an entire topic. That's changeset based too. So based on what I see, I disagree with " topics in vanilla gerrit really aren't that bad" :-) If we were to use Gerrit, I think that we would have to require that branches are squashed to 1 commit except unusual circumstances. So a clarification to what I meant by vanilla Gerrit workflow: for the most part, the workflow would require branches of single or at most a few commits. Longer running branches with 10s of commits would be a major pain to manage in Gerrit and would probably require special handling. -berk On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi wrote: > I'm all for sticking with gerrit. I'll be sad to lose the topic > review interface, but topics in vanilla gerrit really aren't that bad. > We'll still be able to push topics and we'll be able to see all the > changes that make up a topic. I believe that what we lose is 1) the > ability to do a topic-level review and 2) the ability to browse by > topic. > > The only thing that annoys me with gerrit is that when you click > "review", it hides all of the previous review comments until you're > done. Hopefully the new gerrit has fixed this. > > The things I'd like to see in a code review system are: > > - Tight integration with the bugtracker. > > - Some kind of incentive for reviewers, even if it's just gold stars > or a "top reviewer" list. > > Or we could be draconian and enforce a review/submit ratio, just like > the old BBS's enforced upload/download ratios. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sun Aug 24 12:52:34 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 24 Aug 2014 12:52:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I prefer Vanilla Gerrit. I always liked single commits. And, ITK is using pretty much the vanilla workflow. On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci wrote: > Hi David, > > From what I can tell, you can't even get the order of changesets in a topic > in vanilla Gerrit. You can search by a topic but that seems to be it for > topic support. Also, I don't think that there is any way of merging an > entire topic. That's changeset based too. > > So based on what I see, I disagree with " topics in vanilla gerrit really > aren't that bad" :-) If we were to use Gerrit, I think that we would have to > require that branches are squashed to 1 commit except unusual circumstances. > > So a clarification to what I meant by vanilla Gerrit workflow: for the most > part, the workflow would require branches of single or at most a few > commits. Longer running branches with 10s of commits would be a major pain > to manage in Gerrit and would probably require special handling. > > -berk > > > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi wrote: >> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >> review interface, but topics in vanilla gerrit really aren't that bad. >> We'll still be able to push topics and we'll be able to see all the >> changes that make up a topic. I believe that what we lose is 1) the >> ability to do a topic-level review and 2) the ability to browse by >> topic. >> >> The only thing that annoys me with gerrit is that when you click >> "review", it hides all of the previous review comments until you're >> done. Hopefully the new gerrit has fixed this. >> >> The things I'd like to see in a code review system are: >> >> - Tight integration with the bugtracker. >> >> - Some kind of incentive for reviewers, even if it's just gold stars >> or a "top reviewer" list. >> >> Or we could be draconian and enforce a review/submit ratio, just like >> the old BBS's enforced upload/download ratios. >> >> - David > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From andrew.amaclean at gmail.com Sun Aug 24 20:05:35 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 25 Aug 2014 10:05:35 +1000 Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: Hi Berk, After giving this a bit of thought I would prefer the Github/Bitbucket/Gitlab style of workflow. To me the key requirements for a review/testing/integration system are: A) The system itself: - A simple to use (and pretty) web interface that is relatively intuitive. Casual users shouldn't be daunted by the interface. We need their input to enhance the code base. - The enterprise (Kitware) should be able set up and host on its own internal sites. - Integration of bug/issue reporting would be nice. Currently the Mantis system is completely separate. - Branch level access control is essential e.g the VTK Master 6.x and the older VTK 5.10 branch. - Users: Granularity is essential e.g anyone can submit modifications but only a select few have rights to perform merges with the master or designated branches like VTK 6.1 etc. This is just the sandbox principle ... making sure that the code won't break the main release/development branches. - Users: Users should be validated - personally I don't see anything wrong with users providing their real name. - The system itself should be well maintained and responsive to requests for changes. In other words the review/testing/integration code base should be using its own system. B) Reviewing and merging code: - Code definitely needs to be verified by something like cdash at home. - Merges to the master (or a particular branch) only be done after review. - Merges be done by small number of designated personnel that have these rights. - Audit trails are essential. C) Conclusion So I guess I lean towards the Github/Bitbucket/Gitlab style of workflow with possibly Gitlab being able to fulfill all of these requirements (but I not an expert - I have only used Github and Bitbucket, and have just done some reading up on Gitlab). Another key reason to go this way is that a lot of our users in the medical, science and research fields are familiar with the web interface/usage paradigm and they are busy people. Having a web interface that is easy to use allows them to check in when they can and make modifying/adding code and bug submissions etc. easy for them. With respect to the other two workflows: The vanilla gerrit: possibly too complex for the casual user and is missing a nice web interface and bug reporting system. The email workflow: whilst it works with the Linux kernel, we need the user to interact in their own time and place, hence the web interface is much better in this respect. I think you would also need a dedicated mailing list for this, which would reduce the usability for a lot of casual users. Regards Andrew > ---------- Forwarded message ---------- > From: Berk Geveci > To: VTK Developers > Cc: > Date: Sat, 23 Aug 2014 20:13:27 -0400 > Subject: Re: [vtk-developers] VTK code review / testing / integration > workflow > E-mail workflow (similar to Linux kernel): > > In this workflow, discussions on commits/branches happen on the mailing > list. This workflow could be augmented by Web tools such as Github and > Gist. However, merge requests and discussions happen on the mailing list. > > > On Sat, Aug 23, 2014 at 8:07 PM, Berk Geveci > wrote: > >> Vanilla Gerrit workflow: >> >> This workflow is based on reviewing individual commits. Merging also >> happens at individual commit level. Discussions and voting happen per >> commit. >> >> This workflow is almost entirely driven by a Web interface. Discussions >> happen almost entirely in the Web tool. >> >> >> On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci >> wrote: >> >>> Github / Bitbucket / Gitlab style workflow: >>> >>> This workflow is based on pull requests. A process through which anyone >>> with an account can request a particular branch be merged to the original >>> repository. There is usually support for discussion of individual pull >>> requests and possibly support for approving of requests by community >>> members (Bitbucket for example). This workflow supports branches with >>> arbitrary numbers of commits. Diffs for the whole branch and individual >>> commits are provided. The discussion usually happens around the diff of the >>> whole branch. >>> >>> This workflow is almost entirely driven by a Web interface. Discussions >>> happen almost entirely in the Web tool. >>> >>> >>> On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci >>> wrote: >>> >>>> Hi folks, >>>> >>>> It is time for us to look at our options to replace our current Gerrit >>>> instance (review.source.kitware.com). >>>> >>>> Here is some background information: review.source.kitware.com runs a >>>> fork of the Gerrit code base from quite a while ago. The main feature of >>>> the fork is the support for topics (branches). The original Gerrit only >>>> supports reviewing of individual commits (changes) and has no concept of >>>> branches. The lack of support for branches is an issue for us from both >>>> automated testing and review point of view. So we extended Gerrit to >>>> support branches. Alas, our changes have not been accepted upstream and we >>>> are not interested in putting more effort in maintaining the fork as Gerrit >>>> code advances. So we can not make use of new Gerrit features and more >>>> importantly security fixes. So it is time to move on. >>>> >>>> I would like to start this process with a discussion of workflows >>>> (rather than tools). Let's first figure out one or more ideal (and >>>> reasonable) workflows. Then we can discuss tools to achieve these workflows >>>> and make a decision. >>>> >>>> Here I'll list some requirements that I thought are important in no >>>> particular order: >>>> >>>> - Maintain an open and "democratic" review process, a la Gerrit voting >>>> support. >>>> >>>> - The workflow needs to be distributed and not require a single (or a >>>> few) maintainer to integrate code. A la our Gerrit's review and merge >>>> support. >>>> >>>> - Workflow needs to scale with the community size. >>>> >>>> - Support for cdash @ home style testing of code under review before >>>> integration. >>>> >>>> - Support for arbitrary server side checks beyond cdash @ home before >>>> integration. >>>> >>>> - Support for "audit trail". There needs to be way of getting to the >>>> original discussion and reviews that led to the acceptance of a particular >>>> branch. >>>> >>>> I will follow up with a few initial workflow suggestions. Please send >>>> your workflow suggestions or requirements. >>>> >>>> Best, >>>> -berk >>>> >>>> >>>> >>>> >>>> >>> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Aug 25 08:38:25 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 08:38:25 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> Message-ID: <20140825123825.GA512@megas.kitwarein.com> On Sat, Aug 23, 2014 at 22:25:02 -0400, David Thompson wrote: > This reminds me of another Gerrit annoyance: it is very difficult to > get Gerrit to show you the difference between changeset revisions. I > forget whether it happens at the topic or the changeset level, but > Gerrit has a bug that prevents this kind of diff. If someone uploads a > new revision of a topic it is important to be able to see the diffs to > the previous revision, not just the branch point. When viewing a diff, you can click "Patch Sets" at the top to get a bunch of radio buttons to choose the old/new revision to view. --Ben From ben.boeckel at kitware.com Mon Aug 25 08:51:55 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 08:51:55 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: <20140825125155.GB512@megas.kitwarein.com> On Sat, Aug 23, 2014 at 19:58:53 -0400, Berk Geveci wrote: > I will follow up with a few initial workflow suggestions. Please send your > workflow suggestions or requirements. What about the ability to handle "in-progress" branch reviews more gracefully? Currently, there are a couple of things in Gerrit which greatly hinder this: - Gerrit hurks something awful when a commit shows up in two branches (unified-bindings had a branch split off from it and some commits abandoned and/or merged?which broke unified-bindings' review and is presently unviewable in Gerrit at all[1] and cannot be closed or abandoned); - Gerrit is awful at branch dependencies (mainly due to the lack of the concept and attempts being thwarted by the above issue); - Comments are per patch set and not carried over if the commented-on code didn't change which makes fixing half the comments on a review a pain. --Ben [1]http://review.source.kitware.com/#/t/3199/ From dlrdave at aol.com Mon Aug 25 10:24:44 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 10:24:44 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825123825.GA512@megas.kitwarein.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> <20140825123825.GA512@megas.kitwarein.com> Message-ID: <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> >> This reminds me of another Gerrit annoyance: it is very difficult to >> get Gerrit to show you the difference between changeset revisions. > When viewing a diff, you can click "Patch Sets" at the top to get a > bunch of radio buttons to choose the old/new revision to view. That's exactly the view that gets messed up when somebody does a rebase in between patch sets. It's only useful all the time if everybody agrees to avoid rebasing changesets. D From dlrdave at aol.com Mon Aug 25 10:29:27 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 10:29:27 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825125155.GB512@megas.kitwarein.com> References: <20140825125155.GB512@megas.kitwarein.com> Message-ID: <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> > - Gerrit hurks something awful when a commit shows up in two branches > - Gerrit is awful at branch dependencies (mainly due to the lack of > the concept and attempts being thwarted by the above issue); Perhaps, just perhaps, avoiding branch dependencies in the first place is the proper solution to such a problem, rather than requiring your review tool to handle it. Branch dependencies are also hard to handle from a mental/human perspective -- it's not just the tools -- better to have independent branches. Or, to wait for the first branch to make it all the way back to master before starting the second branch. I know, I know. git was supposed to eliminate the need for patience and perseverence, right? ;-) > - Comments are per patch set and not carried over if the commented-on > code didn't change which makes fixing half the comments on a review > a pain. That is a pain -- but is it handled any better in one of the other suggested workflows? D From ben.boeckel at kitware.com Mon Aug 25 11:02:17 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 11:02:17 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> References: <20140825125155.GB512@megas.kitwarein.com> <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> Message-ID: <20140825150217.GA1582@megas.kitwarein.com> On Mon, Aug 25, 2014 at 10:29:27 -0400, David Cole wrote: > Perhaps, just perhaps, avoiding branch dependencies in the first place > is the proper solution to such a problem, rather than requiring your > review tool to handle it. This usually arises from wide-sweeping changes which uncover other, unrelated bugs in the process. For example, my performance changes for CMake uncovered lots of little things which were a nightmare to review as a single codedrop, but were untestable (in terms of finding new bottlenecks) on my end when they were all independent. This meant it got *developed* as a single monolithic set of changes, but merged as logical commits in grouped and bisectable branches. > Branch dependencies are also hard to handle > from a mental/human perspective -- it's not just the tools -- better to > have independent branches. Or, to wait for the first branch to make it > all the way back to master before starting the second branch. I think this is an artificial stall on my time to have to do this. If I have a train of 3 branches to go in, that could take a week before I could *start* the third versus get it all working at once and get a more high-level view of earlier branches (not to mention it's probably real testing of the earlier branches and bugs get found and fixed earlier this way). One place I see this a lot is ParaView changes which require changes in VTK which are untestable without the ParaView end (see unified-bindings or getting VTK's testing up to par so that ParaView can use the infrastructure as well). Context switching is already expensive; let's not force them because of a tool deficiency if possible. > I know, I know. git was supposed to eliminate the need for patience and > perseverence, right? ;-) Not to my knowledge; just be more flexible to different work styles (of which I'm aware mine is not the most common). > > - Comments are per patch set and not carried over if the commented-on > > code didn't change which makes fixing half the comments on a review > > a pain. > > That is a pain -- but is it handled any better in one of the other > suggested workflows? Github seems to attach comments to commit hashes and/or blob hashes, so a rebase or amend will trash the linkings. Reviewboard *might* be able to do it via its pure-diff orientation, but I'm not completely sure. --Ben From berk.geveci at kitware.com Mon Aug 25 10:53:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 10:53:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Bill, David: Can you provide some details on which parts of the Vanilla Gerrit workflow you like? I'd like to understand if these are unique to the Gerrit tool. As far as I can tell, things that are somewhat unique to this workflow are: 1. Encouragement of very short branches, single changesets preferred, 2. Voting (although bitbucket has something like this too), 3. Assignment of multiple reviewers, 4. Keeping around all revisions of a changeset that were created during the review for future audit (Github does not have this, not clear if others have it) Did I miss anything? Which of these are important to prefer Gerrit over other tools? Best, -berk -berk On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen wrote: > I prefer Vanilla Gerrit. I always liked single commits. And, ITK is > using pretty much the vanilla workflow. > > > On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci > wrote: > > Hi David, > > > > From what I can tell, you can't even get the order of changesets in a > topic > > in vanilla Gerrit. You can search by a topic but that seems to be it for > > topic support. Also, I don't think that there is any way of merging an > > entire topic. That's changeset based too. > > > > So based on what I see, I disagree with " topics in vanilla gerrit really > > aren't that bad" :-) If we were to use Gerrit, I think that we would > have to > > require that branches are squashed to 1 commit except unusual > circumstances. > > > > So a clarification to what I meant by vanilla Gerrit workflow: for the > most > > part, the workflow would require branches of single or at most a few > > commits. Longer running branches with 10s of commits would be a major > pain > > to manage in Gerrit and would probably require special handling. > > > > -berk > > > > > > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi > wrote: > >> > >> I'm all for sticking with gerrit. I'll be sad to lose the topic > >> review interface, but topics in vanilla gerrit really aren't that bad. > >> We'll still be able to push topics and we'll be able to see all the > >> changes that make up a topic. I believe that what we lose is 1) the > >> ability to do a topic-level review and 2) the ability to browse by > >> topic. > >> > >> The only thing that annoys me with gerrit is that when you click > >> "review", it hides all of the previous review comments until you're > >> done. Hopefully the new gerrit has fixed this. > >> > >> The things I'd like to see in a code review system are: > >> > >> - Tight integration with the bugtracker. > >> > >> - Some kind of incentive for reviewers, even if it's just gold stars > >> or a "top reviewer" list. > >> > >> Or we could be draconian and enforce a review/submit ratio, just like > >> the old BBS's enforced upload/download ratios. > >> > >> - David > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > 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 ben.boeckel at kitware.com Mon Aug 25 11:05:58 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 11:05:58 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> <20140825123825.GA512@megas.kitwarein.com> <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> Message-ID: <20140825150558.GB1582@megas.kitwarein.com> On Mon, Aug 25, 2014 at 10:24:44 -0400, David Cole wrote: > > When viewing a diff, you can click "Patch Sets" at the top to get a > > bunch of radio buttons to choose the old/new revision to view. > > That's exactly the view that gets messed up when somebody does a rebase > in between patch sets. It's only useful all the time if everybody > agrees to avoid rebasing changesets. Ah, you mean rebase on a different merge-base. When working on branches, I have a script (git-remake; see below) which will rebase on the same merge-base so that the branch is rooted to the same spot, but the commits change. Adding --fork-point for recent-enough git versions (1.9.x?) to the merge-base calculation is recommended for branches which have master merged back into it. --Ben ======= git-remake ======= #!/bin/sh base="${1:-master}" shift exec git rebase -i --autosquash "$@" "$( git merge-base HEAD "$base" )" From utkarsh.ayachit at kitware.com Mon Aug 25 13:24:31 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 13:24:31 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: As I was reading this I tried to mull on why I don't like our current gerrit to see if that'd help me figure out what my vote would be. We want to adopt the same workflow for ParaView too, and I'm afraid squashing all commits into a single commit just doesn't work the several of changes which are core and critical to the evolution of the software. Thus for my personal sake, squashing to a single commit is a non-starter. For the most part, VTK-gerrit does everything I'd want it to do. All my complaints are really user-interface related -- I'm sure everyone has run into them so there's no point hashing those out here. I started looking around for what other gerrit review users are doing and I was pleasantly surprised, on the face. I see that most other gerrit pages look much nicer and cleaner than ours. e.g. https://codereview.qt-project.org/#/q/status:open,n,z https://review.openstack.org/#/q/status:open,n,z http://review.couchbase.org/#/q/status:open,n,z https://gwt-review.googlesource.com/#/q/status:open As I understand, we're using a very old version of gerrit since we had to add support for topic branches. Several of the UI issues do indeed stem from interacting with topic branches. Looking for topic branches in gerrit, I found this: https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches Looking at openstack gerrit, we do see support for topic branches too! https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z The notable difference seems that you can't "review" a topic, you "review" commits in a topic", but in essence that's what we do on VTK-gerrit too, anyways. Utkarsh On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci wrote: > Bill, David: Can you provide some details on which parts of the Vanilla > Gerrit workflow you like? I'd like to understand if these are unique to the > Gerrit tool. As far as I can tell, things that are somewhat unique to this > workflow are: > > 1. Encouragement of very short branches, single changesets preferred, > 2. Voting (although bitbucket has something like this too), > 3. Assignment of multiple reviewers, > 4. Keeping around all revisions of a changeset that were created during > the review for future audit (Github does not have this, not clear if others > have it) > > Did I miss anything? Which of these are important to prefer Gerrit over > other tools? > > Best, > -berk > > > > > > -berk > > > On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen > wrote: > >> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >> using pretty much the vanilla workflow. >> >> >> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >> wrote: >> > Hi David, >> > >> > From what I can tell, you can't even get the order of changesets in a >> topic >> > in vanilla Gerrit. You can search by a topic but that seems to be it for >> > topic support. Also, I don't think that there is any way of merging an >> > entire topic. That's changeset based too. >> > >> > So based on what I see, I disagree with " topics in vanilla gerrit >> really >> > aren't that bad" :-) If we were to use Gerrit, I think that we would >> have to >> > require that branches are squashed to 1 commit except unusual >> circumstances. >> > >> > So a clarification to what I meant by vanilla Gerrit workflow: for the >> most >> > part, the workflow would require branches of single or at most a few >> > commits. Longer running branches with 10s of commits would be a major >> pain >> > to manage in Gerrit and would probably require special handling. >> > >> > -berk >> > >> > >> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >> wrote: >> >> >> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >> >> review interface, but topics in vanilla gerrit really aren't that bad. >> >> We'll still be able to push topics and we'll be able to see all the >> >> changes that make up a topic. I believe that what we lose is 1) the >> >> ability to do a topic-level review and 2) the ability to browse by >> >> topic. >> >> >> >> The only thing that annoys me with gerrit is that when you click >> >> "review", it hides all of the previous review comments until you're >> >> done. Hopefully the new gerrit has fixed this. >> >> >> >> The things I'd like to see in a code review system are: >> >> >> >> - Tight integration with the bugtracker. >> >> >> >> - Some kind of incentive for reviewers, even if it's just gold stars >> >> or a "top reviewer" list. >> >> >> >> Or we could be draconian and enforce a review/submit ratio, just like >> >> the old BBS's enforced upload/download ratios. >> >> >> >> - David >> > >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> 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 > > 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 Mon Aug 25 14:30:11 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 14:30:11 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: <20140825183011.GD29192@megas.kitwarein.com> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > The notable difference seems that you can't "review" a topic, you "review" > commits in a topic", but in essence that's what we do on VTK-gerrit too, > anyways. I think branch-level comments and such are useful (how to test it, why the branch exists, etc.), but we've been without them for a while, so I guess it'd be a high, IMO, Nice To Have?. --Ben From utkarsh.ayachit at kitware.com Mon Aug 25 14:32:48 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 14:32:48 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825183011.GD29192@megas.kitwarein.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: Just looking at a topic discussion in github ( https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do most of what gerrit does, but in prettier/nicer way. In which case I think moving to github would be my vote. Also we can easily integrate documentation, bug tracker etc. -- so wiki's can slowly fade away! Utkarsh On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel wrote: > On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > > The notable difference seems that you can't "review" a topic, you > "review" > > commits in a topic", but in essence that's what we do on VTK-gerrit too, > > anyways. > > I think branch-level comments and such are useful (how to test it, why > the branch exists, etc.), but we've been without them for a while, so I > guess it'd be a high, IMO, Nice To Have?. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Aug 25 14:34:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 14:34:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I encourage everyone to think in terms of the workflow(s) that we prefer rather than tools. If we start with "can we live with vanilla gerrit", the answer is going to be yes for most people. However, this is only part of the picture. Some folks mentioned bug tracker integration, others support for rich content such as markdown etc. Integration with cdash @ home is an obvious one. These are good examples of what we want in workflows. Once we have a decent understanding of what people want the workflow to be, we can discuss tools more deeply. So I am interpreting Utkarsh's email as "Thus for my personal sake, squashing to a single commit is a non-starter". And yes, we can manage multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's workflow requirements using pretty much any other tool be it Github/Gitlab/Bitbucket or even mailing list. Since we have to migrate, let's use it as an opportunity and think about upgrading our overall workflow. -berk On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > As I was reading this I tried to mull on why I don't like our current > gerrit to see if that'd help me figure out what my vote would be. > > We want to adopt the same workflow for ParaView too, and I'm afraid > squashing all commits into a single commit just doesn't work the several of > changes which are core and critical to the evolution of the software. Thus > for my personal sake, squashing to a single commit is a non-starter. > > For the most part, VTK-gerrit does everything I'd want it to do. All my > complaints are really user-interface related -- I'm sure everyone has run > into them so there's no point hashing those out here. I started looking > around for what other gerrit review users are doing and I was pleasantly > surprised, on the face. I see that most other gerrit pages look much nicer > and cleaner than ours. > e.g. > > https://codereview.qt-project.org/#/q/status:open,n,z > https://review.openstack.org/#/q/status:open,n,z > http://review.couchbase.org/#/q/status:open,n,z > https://gwt-review.googlesource.com/#/q/status:open > > As I understand, we're using a very old version of gerrit since we had to > add support for topic branches. Several of the UI issues do indeed stem > from interacting with topic branches. Looking for topic branches in gerrit, > I found this: > https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches > > Looking at openstack gerrit, we do see support for topic branches too! > > > https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z > > The notable difference seems that you can't "review" a topic, you "review" > commits in a topic", but in essence that's what we do on VTK-gerrit too, > anyways. > > Utkarsh > > > > > On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci > wrote: > >> Bill, David: Can you provide some details on which parts of the Vanilla >> Gerrit workflow you like? I'd like to understand if these are unique to the >> Gerrit tool. As far as I can tell, things that are somewhat unique to this >> workflow are: >> >> 1. Encouragement of very short branches, single changesets preferred, >> 2. Voting (although bitbucket has something like this too), >> 3. Assignment of multiple reviewers, >> 4. Keeping around all revisions of a changeset that were created during >> the review for future audit (Github does not have this, not clear if others >> have it) >> >> Did I miss anything? Which of these are important to prefer Gerrit over >> other tools? >> >> Best, >> -berk >> >> >> >> >> >> -berk >> >> >> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >> wrote: >> >>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>> using pretty much the vanilla workflow. >>> >>> >>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>> wrote: >>> > Hi David, >>> > >>> > From what I can tell, you can't even get the order of changesets in a >>> topic >>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>> for >>> > topic support. Also, I don't think that there is any way of merging an >>> > entire topic. That's changeset based too. >>> > >>> > So based on what I see, I disagree with " topics in vanilla gerrit >>> really >>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>> have to >>> > require that branches are squashed to 1 commit except unusual >>> circumstances. >>> > >>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>> most >>> > part, the workflow would require branches of single or at most a few >>> > commits. Longer running branches with 10s of commits would be a major >>> pain >>> > to manage in Gerrit and would probably require special handling. >>> > >>> > -berk >>> > >>> > >>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>> wrote: >>> >> >>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>> >> review interface, but topics in vanilla gerrit really aren't that bad. >>> >> We'll still be able to push topics and we'll be able to see all the >>> >> changes that make up a topic. I believe that what we lose is 1) the >>> >> ability to do a topic-level review and 2) the ability to browse by >>> >> topic. >>> >> >>> >> The only thing that annoys me with gerrit is that when you click >>> >> "review", it hides all of the previous review comments until you're >>> >> done. Hopefully the new gerrit has fixed this. >>> >> >>> >> The things I'd like to see in a code review system are: >>> >> >>> >> - Tight integration with the bugtracker. >>> >> >>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>> >> or a "top reviewer" list. >>> >> >>> >> Or we could be draconian and enforce a review/submit ratio, just like >>> >> the old BBS's enforced upload/download ratios. >>> >> >>> >> - David >>> > >>> > >>> > >>> > _______________________________________________ >>> > Powered by www.kitware.com >>> > >>> > Visit other Kitware open-source projects at >>> > http://www.kitware.com/opensource/opensource.html >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >>> > >>> >>> >>> >>> -- >>> 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 >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Aug 25 14:38:01 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 25 Aug 2014 14:38:01 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Just looking at a topic discussion in github ( > https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do > most of what gerrit does, but in prettier/nicer way. In which case I think > moving to github would be my vote. Also we can easily integrate > documentation, bug tracker etc. -- so wiki's can slowly fade away! > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long discussion). I think its simple enough. I think it covers the basic features we need in a reasonable easy to use manner. Also, as I know that github team is working on improving it further in the future (more features). - Aashish > > Utkarsh > > > > > On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel > wrote: > >> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: >> > The notable difference seems that you can't "review" a topic, you >> "review" >> > commits in a topic", but in essence that's what we do on VTK-gerrit too, >> > anyways. >> >> I think branch-level comments and such are useful (how to test it, why >> the branch exists, etc.), but we've been without them for a while, so I >> guess it'd be a high, IMO, Nice To Have?. >> >> --Ben >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 robert.maynard at kitware.com Mon Aug 25 15:12:35 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 25 Aug 2014 15:12:35 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: On a side topic. I know that CDash restful API has been improved lately, so now we can integrate CDash reports into commenting systems. For example I have a proof of concept here: https://github.com/robertmaynard/Remus/pull/108 . Github/Gitlab both have a great web service hook system that should allow us to initiate builds from pull requests. On Mon, Aug 25, 2014 at 2:38 PM, Aashish Chaudhary wrote: > On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit > wrote: >> >> Just looking at a topic discussion in github ( >> https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do >> most of what gerrit does, but in prettier/nicer way. In which case I think >> moving to github would be my vote. Also we can easily integrate >> documentation, bug tracker etc. -- so wiki's can slowly fade away! > > > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long > discussion). I think its simple enough. I think it covers the basic features > we need in a reasonable easy to use manner. Also, as I know that github team > is working on improving it further in the future (more features). > > - Aashish > >> >> >> Utkarsh >> >> >> >> >> On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel >> wrote: >>> >>> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: >>> > The notable difference seems that you can't "review" a topic, you >>> > "review" >>> > commits in a topic", but in essence that's what we do on VTK-gerrit >>> > too, >>> > anyways. >>> >>> I think branch-level comments and such are useful (how to test it, why >>> the branch exists, etc.), but we've been without them for a while, so I >>> guess it'd be a high, IMO, Nice To Have?. >>> >>> --Ben >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From utkarsh.ayachit at kitware.com Mon Aug 25 15:19:06 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 15:19:06 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: Very cool! On Mon, Aug 25, 2014 at 3:12 PM, Robert Maynard wrote: > On a side topic. I know that CDash restful API has been improved > lately, so now we can integrate CDash reports into commenting systems. > For example I have a proof of concept here: > https://github.com/robertmaynard/Remus/pull/108 . Github/Gitlab both > have a great web service hook system that should allow us to initiate > builds from pull requests. > > > On Mon, Aug 25, 2014 at 2:38 PM, Aashish Chaudhary > wrote: > > On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit > > wrote: > >> > >> Just looking at a topic discussion in github ( > >> https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can > do > >> most of what gerrit does, but in prettier/nicer way. In which case I > think > >> moving to github would be my vote. Also we can easily integrate > >> documentation, bug tracker etc. -- so wiki's can slowly fade away! > > > > > > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long > > discussion). I think its simple enough. I think it covers the basic > features > > we need in a reasonable easy to use manner. Also, as I know that github > team > > is working on improving it further in the future (more features). > > > > - Aashish > > > >> > >> > >> Utkarsh > >> > >> > >> > >> > >> On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel > >> wrote: > >>> > >>> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > >>> > The notable difference seems that you can't "review" a topic, you > >>> > "review" > >>> > commits in a topic", but in essence that's what we do on VTK-gerrit > >>> > too, > >>> > anyways. > >>> > >>> I think branch-level comments and such are useful (how to test it, why > >>> the branch exists, etc.), but we've been without them for a while, so I > >>> guess it'd be a high, IMO, Nice To Have?. > >>> > >>> --Ben > >> > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Aug 25 15:27:55 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 25 Aug 2014 15:27:55 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: My preferred workflow as a developer would be: 1. Create a topic / pull request. 2. I assign people to review topic 3. Automatic integration builds start going to work. 4. Something reports back to the status of the build and tests, which notifies the author and reviewers that building and testing have finished. 5. Reviewers decide based on code and build status if code is worth merging. When changes happen: 1. I extend the topic with fixes based on review or integration tests, or squash changes back into the original topic as they are style/spelling issues. 2. Automatic integration starts up again 3. The commenters are notified that author has modified the topic 4. Commenters can easily see the difference between the old and new versions. As a reviewer I desire a different set of features: 1. Ability to comment inline with the code 2. Easy way to generate a single view of all the changes for a topic 3. Ability to easily see if the topic has broken the build or tests. 5. A way to force a re-build or re-test of a topic incase I believe something was caused by a machine failure 6. Ability to bring other people into the conversation. Be it through '@' tags or adding people as reviewers. 7. Ability to get emails on a per project / topic level On Mon, Aug 25, 2014 at 2:34 PM, Berk Geveci wrote: > I encourage everyone to think in terms of the workflow(s) that we prefer > rather than tools. If we start with "can we live with vanilla gerrit", the > answer is going to be yes for most people. However, this is only part of the > picture. Some folks mentioned bug tracker integration, others support for > rich content such as markdown etc. Integration with cdash @ home is an > obvious one. These are good examples of what we want in workflows. Once we > have a decent understanding of what people want the workflow to be, we can > discuss tools more deeply. > > So I am interpreting Utkarsh's email as "Thus for my personal sake, > squashing to a single commit is a non-starter". And yes, we can manage > multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's > workflow requirements using pretty much any other tool be it > Github/Gitlab/Bitbucket or even mailing list. > > Since we have to migrate, let's use it as an opportunity and think about > upgrading our overall workflow. > > -berk > > > On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit > wrote: >> >> As I was reading this I tried to mull on why I don't like our current >> gerrit to see if that'd help me figure out what my vote would be. >> >> We want to adopt the same workflow for ParaView too, and I'm afraid >> squashing all commits into a single commit just doesn't work the several of >> changes which are core and critical to the evolution of the software. Thus >> for my personal sake, squashing to a single commit is a non-starter. >> >> For the most part, VTK-gerrit does everything I'd want it to do. All my >> complaints are really user-interface related -- I'm sure everyone has run >> into them so there's no point hashing those out here. I started looking >> around for what other gerrit review users are doing and I was pleasantly >> surprised, on the face. I see that most other gerrit pages look much nicer >> and cleaner than ours. >> e.g. >> >> https://codereview.qt-project.org/#/q/status:open,n,z >> https://review.openstack.org/#/q/status:open,n,z >> http://review.couchbase.org/#/q/status:open,n,z >> https://gwt-review.googlesource.com/#/q/status:open >> >> As I understand, we're using a very old version of gerrit since we had to >> add support for topic branches. Several of the UI issues do indeed stem from >> interacting with topic branches. Looking for topic branches in gerrit, I >> found this: >> https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches >> >> Looking at openstack gerrit, we do see support for topic branches too! >> >> >> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z >> >> The notable difference seems that you can't "review" a topic, you "review" >> commits in a topic", but in essence that's what we do on VTK-gerrit too, >> anyways. >> >> Utkarsh >> >> >> >> >> On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci >> wrote: >>> >>> Bill, David: Can you provide some details on which parts of the Vanilla >>> Gerrit workflow you like? I'd like to understand if these are unique to the >>> Gerrit tool. As far as I can tell, things that are somewhat unique to this >>> workflow are: >>> >>> 1. Encouragement of very short branches, single changesets preferred, >>> 2. Voting (although bitbucket has something like this too), >>> 3. Assignment of multiple reviewers, >>> 4. Keeping around all revisions of a changeset that were created during >>> the review for future audit (Github does not have this, not clear if others >>> have it) >>> >>> Did I miss anything? Which of these are important to prefer Gerrit over >>> other tools? >>> >>> Best, >>> -berk >>> >>> >>> >>> >>> >>> -berk >>> >>> >>> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >>> wrote: >>>> >>>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>>> using pretty much the vanilla workflow. >>>> >>>> >>>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>>> wrote: >>>> > Hi David, >>>> > >>>> > From what I can tell, you can't even get the order of changesets in a >>>> > topic >>>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>>> > for >>>> > topic support. Also, I don't think that there is any way of merging an >>>> > entire topic. That's changeset based too. >>>> > >>>> > So based on what I see, I disagree with " topics in vanilla gerrit >>>> > really >>>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>>> > have to >>>> > require that branches are squashed to 1 commit except unusual >>>> > circumstances. >>>> > >>>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>>> > most >>>> > part, the workflow would require branches of single or at most a few >>>> > commits. Longer running branches with 10s of commits would be a major >>>> > pain >>>> > to manage in Gerrit and would probably require special handling. >>>> > >>>> > -berk >>>> > >>>> > >>>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>>> > wrote: >>>> >> >>>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>>> >> review interface, but topics in vanilla gerrit really aren't that >>>> >> bad. >>>> >> We'll still be able to push topics and we'll be able to see all the >>>> >> changes that make up a topic. I believe that what we lose is 1) the >>>> >> ability to do a topic-level review and 2) the ability to browse by >>>> >> topic. >>>> >> >>>> >> The only thing that annoys me with gerrit is that when you click >>>> >> "review", it hides all of the previous review comments until you're >>>> >> done. Hopefully the new gerrit has fixed this. >>>> >> >>>> >> The things I'd like to see in a code review system are: >>>> >> >>>> >> - Tight integration with the bugtracker. >>>> >> >>>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>>> >> or a "top reviewer" list. >>>> >> >>>> >> Or we could be draconian and enforce a review/submit ratio, just like >>>> >> the old BBS's enforced upload/download ratios. >>>> >> >>>> >> - David >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Powered by www.kitware.com >>>> > >>>> > Visit other Kitware open-source projects at >>>> > http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From dlrdave at aol.com Mon Aug 25 15:50:59 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 15:50:59 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> > My preferred workflow as a developer would be: > ... > 2. I assign people to review topic > ... +1 all the way -- this sounds like a fantastic workflow. One additional requirement I would impose on the workflow is that automatic build/test kickoff only be allowed by requests from a list of trusted individuals. If you're not on the list, you have to ask somebody who is on the list to kick it off for you. A fantasy feature for me would be that the system injects a step 1.5/2.5 in the developer workflow, and automatically chooses 3-5 reviewers for you based on reviewers "signing up" for reviewing certain modules, or perhaps based on recent-ish commits in the same files... Also, one more: it would be nice to have the merge be automatic as soon as it's "approved." (extension to Rob's Dev workflow: Step 6. Automatic merge upon approval.) David C. From bill.lorensen at gmail.com Mon Aug 25 16:28:45 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 16:28:45 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Robert, A +1. To me it looks like our current gerrit workflow. On Mon, Aug 25, 2014 at 3:27 PM, Robert Maynard wrote: > My preferred workflow as a developer would be: > > 1. Create a topic / pull request. > 2. I assign people to review topic > 3. Automatic integration builds start going to work. > 4. Something reports back to the status of the build and tests, which > notifies the author > and reviewers that building and testing have finished. > 5. Reviewers decide based on code and build status if code is worth merging. > > When changes happen: > 1. I extend the topic with fixes based on review or integration tests, > or squash changes back > into the original topic as they are style/spelling issues. > 2. Automatic integration starts up again > 3. The commenters are notified that author has modified the topic > 4. Commenters can easily see the difference between the old and new versions. > > > As a reviewer I desire a different set of features: > > 1. Ability to comment inline with the code > 2. Easy way to generate a single view of all the changes for a topic > 3. Ability to easily see if the topic has broken the build or tests. > 5. A way to force a re-build or re-test of a topic incase I believe something > was caused by a machine failure > 6. Ability to bring other people into the conversation. Be it through > '@' tags or > adding people as reviewers. > 7. Ability to get emails on a per project / topic level > > > On Mon, Aug 25, 2014 at 2:34 PM, Berk Geveci wrote: >> I encourage everyone to think in terms of the workflow(s) that we prefer >> rather than tools. If we start with "can we live with vanilla gerrit", the >> answer is going to be yes for most people. However, this is only part of the >> picture. Some folks mentioned bug tracker integration, others support for >> rich content such as markdown etc. Integration with cdash @ home is an >> obvious one. These are good examples of what we want in workflows. Once we >> have a decent understanding of what people want the workflow to be, we can >> discuss tools more deeply. >> >> So I am interpreting Utkarsh's email as "Thus for my personal sake, >> squashing to a single commit is a non-starter". And yes, we can manage >> multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's >> workflow requirements using pretty much any other tool be it >> Github/Gitlab/Bitbucket or even mailing list. >> >> Since we have to migrate, let's use it as an opportunity and think about >> upgrading our overall workflow. >> >> -berk >> >> >> On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit >> wrote: >>> >>> As I was reading this I tried to mull on why I don't like our current >>> gerrit to see if that'd help me figure out what my vote would be. >>> >>> We want to adopt the same workflow for ParaView too, and I'm afraid >>> squashing all commits into a single commit just doesn't work the several of >>> changes which are core and critical to the evolution of the software. Thus >>> for my personal sake, squashing to a single commit is a non-starter. >>> >>> For the most part, VTK-gerrit does everything I'd want it to do. All my >>> complaints are really user-interface related -- I'm sure everyone has run >>> into them so there's no point hashing those out here. I started looking >>> around for what other gerrit review users are doing and I was pleasantly >>> surprised, on the face. I see that most other gerrit pages look much nicer >>> and cleaner than ours. >>> e.g. >>> >>> https://codereview.qt-project.org/#/q/status:open,n,z >>> https://review.openstack.org/#/q/status:open,n,z >>> http://review.couchbase.org/#/q/status:open,n,z >>> https://gwt-review.googlesource.com/#/q/status:open >>> >>> As I understand, we're using a very old version of gerrit since we had to >>> add support for topic branches. Several of the UI issues do indeed stem from >>> interacting with topic branches. Looking for topic branches in gerrit, I >>> found this: >>> https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches >>> >>> Looking at openstack gerrit, we do see support for topic branches too! >>> >>> >>> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z >>> >>> The notable difference seems that you can't "review" a topic, you "review" >>> commits in a topic", but in essence that's what we do on VTK-gerrit too, >>> anyways. >>> >>> Utkarsh >>> >>> >>> >>> >>> On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci >>> wrote: >>>> >>>> Bill, David: Can you provide some details on which parts of the Vanilla >>>> Gerrit workflow you like? I'd like to understand if these are unique to the >>>> Gerrit tool. As far as I can tell, things that are somewhat unique to this >>>> workflow are: >>>> >>>> 1. Encouragement of very short branches, single changesets preferred, >>>> 2. Voting (although bitbucket has something like this too), >>>> 3. Assignment of multiple reviewers, >>>> 4. Keeping around all revisions of a changeset that were created during >>>> the review for future audit (Github does not have this, not clear if others >>>> have it) >>>> >>>> Did I miss anything? Which of these are important to prefer Gerrit over >>>> other tools? >>>> >>>> Best, >>>> -berk >>>> >>>> >>>> >>>> >>>> >>>> -berk >>>> >>>> >>>> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >>>> wrote: >>>>> >>>>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>>>> using pretty much the vanilla workflow. >>>>> >>>>> >>>>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>>>> wrote: >>>>> > Hi David, >>>>> > >>>>> > From what I can tell, you can't even get the order of changesets in a >>>>> > topic >>>>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>>>> > for >>>>> > topic support. Also, I don't think that there is any way of merging an >>>>> > entire topic. That's changeset based too. >>>>> > >>>>> > So based on what I see, I disagree with " topics in vanilla gerrit >>>>> > really >>>>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>>>> > have to >>>>> > require that branches are squashed to 1 commit except unusual >>>>> > circumstances. >>>>> > >>>>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>>>> > most >>>>> > part, the workflow would require branches of single or at most a few >>>>> > commits. Longer running branches with 10s of commits would be a major >>>>> > pain >>>>> > to manage in Gerrit and would probably require special handling. >>>>> > >>>>> > -berk >>>>> > >>>>> > >>>>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>>>> > wrote: >>>>> >> >>>>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>>>> >> review interface, but topics in vanilla gerrit really aren't that >>>>> >> bad. >>>>> >> We'll still be able to push topics and we'll be able to see all the >>>>> >> changes that make up a topic. I believe that what we lose is 1) the >>>>> >> ability to do a topic-level review and 2) the ability to browse by >>>>> >> topic. >>>>> >> >>>>> >> The only thing that annoys me with gerrit is that when you click >>>>> >> "review", it hides all of the previous review comments until you're >>>>> >> done. Hopefully the new gerrit has fixed this. >>>>> >> >>>>> >> The things I'd like to see in a code review system are: >>>>> >> >>>>> >> - Tight integration with the bugtracker. >>>>> >> >>>>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>>>> >> or a "top reviewer" list. >>>>> >> >>>>> >> Or we could be draconian and enforce a review/submit ratio, just like >>>>> >> the old BBS's enforced upload/download ratios. >>>>> >> >>>>> >> - David >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Powered by www.kitware.com >>>>> > >>>>> > Visit other Kitware open-source projects at >>>>> > http://www.kitware.com/opensource/opensource.html >>>>> > >>>>> > Follow this link to subscribe/unsubscribe: >>>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> 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 >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Mon Aug 25 16:45:30 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 25 Aug 2014 16:45:30 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> Message-ID: <20140825204530.1173865063@mail.rogue-research.com> On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >A fantasy feature for me would be that the system injects a step >1.5/2.5 in the developer workflow, and automatically chooses 3-5 >reviewers for you based on reviewers "signing up" for reviewing certain >modules, or perhaps based on recent-ish commits in the same files... That would be a great addition. I often don't know who to add as a reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A person can use 'git log' and 'git blame' to get some guesses, and that could be automated. Of course, sometimes that results in suggesting someone no longer involved with VTK or the infamous 'VTK developers', but still it would help to automate it. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Mon Aug 25 16:54:16 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 16:54:16 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825204530.1173865063@mail.rogue-research.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: BTW the new gerrit UI is a bit prettier: https://android-review.googlesource.com/#/q/status:open I'm a little concerned that we spend too much time on process and not enough time on improving VTK. But, I'll go with the consensus of the people who still work for a living. If the new process is too difficult for an old guy like me, I'll just spend my extra time with ITK. Bill On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride wrote: > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: > >>A fantasy feature for me would be that the system injects a step >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >>reviewers for you based on reviewers "signing up" for reviewing certain >>modules, or perhaps based on recent-ish commits in the same files... > > That would be a great addition. I often don't know who to add as a reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A person can use 'git log' and 'git blame' to get some guesses, and that could be automated. Of course, sometimes that results in suggesting someone no longer involved with VTK or the infamous 'VTK developers', but still it would help to automate it. > > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Mon Aug 25 19:47:10 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 19:47:10 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Hi Bill, The goal is not to have more process. It is to implement a workflow with fun-to-use tools such that we can continue to attract developers to VTK. VTK development is lively. We have done a lot of great stuff last year, both new development and maintenance, and we have great things coming next year. In my humble opinion, what we are doing poorly is attracting new developers. I think toolchain and workflow play a role in this. Not communicating well is another part. I'd like to attract more people to contribute code and more people to do reviews. Also, our bug tracker is collecting dust. Lots of bug reports are going in but it gets very little attention. I can't even remember when I looked at it last. Here are some statistics from openhub.net (website formerly known as ohloh): VTK: 30 Day Summary Jul 21 2014 ? Aug 20 2014 152 Commits 19 Contributors 12 Month Summary Aug 20 2013 ? Aug 20 2014 2393 Commits Down -965 (28%) from previous 12 months 64 Contributors Down -6 (8%) from previous 12 months Still a lot of commits but going down. So I'd like to see us slowly migrating towards tools that are more attractive and facilitate collaboration with the larger community. Frankly, I believe that our current set of tools get in the way. First of all, they all require creating accounts to do anything. An account for bug tracker, another for Gerrit, another for Wiki, another 2 for the mailing lists. We should have presence where people already hang out and don't have to create new accounts. Github, stackoverflow, Google+ etc. Second of all, they are all clunky at best. Usability does matter to people. Finally, there are a lot new resources available out there and we are not tapping into it as best as we can. We should be using Travis and Jenkins in addition to CDash and CDash @ Home for example. So I don't think that this conversation is overkill. These discussions have a natural tendency to go on forever, I agree. So let's try to keep to the point and make some decisions soon. Best, -berk On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen wrote: > BTW the new gerrit UI is a bit prettier: > https://android-review.googlesource.com/#/q/status:open > > I'm a little concerned that we spend too much time on process and not > enough time on improving VTK. But, I'll go with the consensus of the > people who still work for a living. If the new process is too > difficult for an old guy like me, I'll just spend my extra time with > ITK. > > Bill > > > On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride > wrote: > > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: > > > >>A fantasy feature for me would be that the system injects a step > >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 > >>reviewers for you based on reviewers "signing up" for reviewing certain > >>modules, or perhaps based on recent-ish commits in the same files... > > > > That would be a great addition. I often don't know who to add as a > reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A > person can use 'git log' and 'git blame' to get some guesses, and that > could be automated. Of course, sometimes that results in suggesting > someone no longer involved with VTK or the infamous 'VTK developers', but > still it would help to automate it. > > > > 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 > > > > 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 david.gobbi at gmail.com Mon Aug 25 19:55:04 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 25 Aug 2014 17:55:04 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: In general, I'd be happy with pretty much any tool, even the linux method of doing everything via email sounds fine to me. Getting back to workflow, here are the only things that I see as absolutely essential: - mandatory testing prior to merge - mandatory review and approval - reviews must be taken seriously by all parties, they're not just a hoop to jump through Here are additional workflow steps that I'd like to see: - a lightweight proposal process for large changes - all reported bugs should be assessed and assigned For bugs, ideally all developers should watch the bugtracker, but it might be necessary for there to be a developer assigned to watching for reports. We're never going to grow our community if we ignore bug reports (or if we consistently ignore questions on the mailing list). - David From bill.lorensen at gmail.com Mon Aug 25 21:17:46 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 21:17:46 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Berk, If the goal is to attract more developers then we need to understand why we are not attracting them. We should not assume that changing our process is a solution. I think the process discussion is a good one, but it may not be the core issue. I suggest we start another thread to address the developer issue. Bill On Aug 25, 2014 7:47 PM, "Berk Geveci" wrote: > Hi Bill, > > The goal is not to have more process. It is to implement a workflow with > fun-to-use tools such that we can continue to attract developers to VTK. > VTK development is lively. We have done a lot of great stuff last year, > both new development and maintenance, and we have great things coming next > year. > > In my humble opinion, what we are doing poorly is attracting new > developers. I think toolchain and workflow play a role in this. Not > communicating well is another part. I'd like to attract more people to > contribute code and more people to do reviews. Also, our bug tracker is > collecting dust. Lots of bug reports are going in but it gets very little > attention. I can't even remember when I looked at it last. > > Here are some statistics from openhub.net (website formerly known as > ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 ? Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 ? Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First of > all, they all require creating accounts to do anything. An account for bug > tracker, another for Gerrit, another for Wiki, another 2 for the mailing > lists. We should have presence where people already hang out and don't have > to create new accounts. Github, stackoverflow, Google+ etc. Second of all, > they are all clunky at best. Usability does matter to people. Finally, > there are a lot new resources available out there and we are not tapping > into it as best as we can. We should be using Travis and Jenkins in > addition to CDash and CDash @ Home for example. > > So I don't think that this conversation is overkill. These discussions > have a natural tendency to go on forever, I agree. So let's try to keep to > the point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > wrote: > >> BTW the new gerrit UI is a bit prettier: >> https://android-review.googlesource.com/#/q/status:open >> >> I'm a little concerned that we spend too much time on process and not >> enough time on improving VTK. But, I'll go with the consensus of the >> people who still work for a living. If the new process is too >> difficult for an old guy like me, I'll just spend my extra time with >> ITK. >> >> Bill >> >> >> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >> wrote: >> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >> > >> >>A fantasy feature for me would be that the system injects a step >> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >> >>reviewers for you based on reviewers "signing up" for reviewing certain >> >>modules, or perhaps based on recent-ish commits in the same files... >> > >> > That would be a great addition. I often don't know who to add as a >> reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >> person can use 'git log' and 'git blame' to get some guesses, and that >> could be automated. Of course, sometimes that results in suggesting >> someone no longer involved with VTK or the infamous 'VTK developers', but >> still it would help to automate it. >> > >> > 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 >> > >> > 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 burlen.loring at gmail.com Tue Aug 26 12:52:40 2014 From: burlen.loring at gmail.com (Burlen Loring) Date: Tue, 26 Aug 2014 09:52:40 -0700 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: <53FCBB58.5090405@gmail.com> I wanted to comment that your gerrit work flow is great. I like the organization by topic branches and that dashboard runs are automatically triggered on new pushes. Also the reviews by folks on your side have been very helpful in improving the submitted code. It would be nice to see a diff between successive review/recommit iterations. I don't know how much the work flow is turning off new developers, a knee jerk reaction is that it feels like overkill, but all of the things that you ask folks to do make a lot of sense and help keep VTK solid. It sure is rewarding to see how solid VTK is and see it's continual improvement and to be a part of that! As a developer the high quality of the resulting product outs weigh my desire to work with fun tools. I recently made some commits to a KDE component project. Their workflow uses svn+reviewboard. The lack of topic branches made iteration cumbersome. Once the patches were approved merging was not as easy as it is in your gerrit workflow where it's done with a simple button click on a web page. I would think that modernization is more of an issue in attracting developers. Ancient OpenGL infrastructure is a really big one. Things like having to use SafeDownCast instead of dynamic_cast and the other baggage of supporting ancient compilers are also a big turnoff. A full c++11 port would be very exciting. All these are things you are working on but are harder and take longer to change... On 08/25/2014 04:47 PM, Berk Geveci wrote: > Hi Bill, > > The goal is not to have more process. It is to implement a workflow > with fun-to-use tools such that we can continue to attract developers > to VTK. VTK development is lively. We have done a lot of great stuff > last year, both new development and maintenance, and we have great > things coming next year. > > In my humble opinion, what we are doing poorly is attracting new > developers. I think toolchain and workflow play a role in this. Not > communicating well is another part. I'd like to attract more people to > contribute code and more people to do reviews. Also, our bug tracker > is collecting dust. Lots of bug reports are going in but it gets very > little attention. I can't even remember when I looked at it last. > > Here are some statistics from openhub.net > (website formerly known as ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 --- Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 --- Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First > of all, they all require creating accounts to do anything. An account > for bug tracker, another for Gerrit, another for Wiki, another 2 for > the mailing lists. We should have presence where people already hang > out and don't have to create new accounts. Github, stackoverflow, > Google+ etc. Second of all, they are all clunky at best. Usability > does matter to people. Finally, there are a lot new resources > available out there and we are not tapping into it as best as we can. > We should be using Travis and Jenkins in addition to CDash and CDash @ > Home for example. > > So I don't think that this conversation is overkill. These discussions > have a natural tendency to go on forever, I agree. So let's try to > keep to the point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > > wrote: > > BTW the new gerrit UI is a bit prettier: > https://android-review.googlesource.com/#/q/status:open > > I'm a little concerned that we spend too much time on process and not > enough time on improving VTK. But, I'll go with the consensus of the > people who still work for a living. If the new process is too > difficult for an old guy like me, I'll just spend my extra time with > ITK. > > Bill > > > On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride > > wrote: > > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via > vtk-developers said: > > > >>A fantasy feature for me would be that the system injects a step > >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 > >>reviewers for you based on reviewers "signing up" for reviewing > certain > >>modules, or perhaps based on recent-ish commits in the same files... > > > > That would be a great addition. I often don't know who to add > as a reviewer, and I've been tinkering with VTK for years. > Imagine a newbie! A person can use 'git log' and 'git blame' to > get some guesses, and that could be automated. Of course, > sometimes that results in suggesting someone no longer involved > with VTK or the infamous 'VTK developers', but still it would help > to automate it. > > > > 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Aug 26 14:46:25 2014 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 26 Aug 2014 14:46:25 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <53FCBB58.5090405@gmail.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: This is in the "would be nice to have" category. Based on recent personal experience and the experience of others updating VTK versions, I would like to see performance regression tests in VTK (e.g., changes to memory consumption, execution time, rendering frame rate, etc.) with the results of the tests reported in the review workflow. That way developers and reviewers could easily reject changes that cause unacceptable performance regressions. I realize this might not be the easiest thing to implement, and would require changes beyond the review system, but it would be very nice. CDash reports a history of the execution time of tests, but this isn't always helpful in its current form. - Cory On Tue, Aug 26, 2014 at 12:52 PM, Burlen Loring wrote: > I wanted to comment that your gerrit work flow is great. I like the > organization by topic branches and that dashboard runs are automatically > triggered on new pushes. Also the reviews by folks on your side have been > very helpful in improving the submitted code. It would be nice to see a diff > between successive review/recommit iterations. > > I don't know how much the work flow is turning off new developers, a knee > jerk reaction is that it feels like overkill, but all of the things that you > ask folks to do make a lot of sense and help keep VTK solid. It sure is > rewarding to see how solid VTK is and see it's continual improvement and to > be a part of that! As a developer the high quality of the resulting product > outs weigh my desire to work with fun tools. > > I recently made some commits to a KDE component project. Their workflow uses > svn+reviewboard. The lack of topic branches made iteration cumbersome. Once > the patches were approved merging was not as easy as it is in your gerrit > workflow where it's done with a simple button click on a web page. > > I would think that modernization is more of an issue in attracting > developers. Ancient OpenGL infrastructure is a really big one. Things like > having to use SafeDownCast instead of dynamic_cast and the other baggage of > supporting ancient compilers are also a big turnoff. A full c++11 port would > be very exciting. All these are things you are working on but are harder and > take longer to change... > > > On 08/25/2014 04:47 PM, Berk Geveci wrote: > > Hi Bill, > > The goal is not to have more process. It is to implement a workflow with > fun-to-use tools such that we can continue to attract developers to VTK. VTK > development is lively. We have done a lot of great stuff last year, both new > development and maintenance, and we have great things coming next year. > > In my humble opinion, what we are doing poorly is attracting new developers. > I think toolchain and workflow play a role in this. Not communicating well > is another part. I'd like to attract more people to contribute code and more > people to do reviews. Also, our bug tracker is collecting dust. Lots of bug > reports are going in but it gets very little attention. I can't even > remember when I looked at it last. > > Here are some statistics from openhub.net (website formerly known as ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 ? Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 ? Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First of > all, they all require creating accounts to do anything. An account for bug > tracker, another for Gerrit, another for Wiki, another 2 for the mailing > lists. We should have presence where people already hang out and don't have > to create new accounts. Github, stackoverflow, Google+ etc. Second of all, > they are all clunky at best. Usability does matter to people. Finally, there > are a lot new resources available out there and we are not tapping into it > as best as we can. We should be using Travis and Jenkins in addition to > CDash and CDash @ Home for example. > > So I don't think that this conversation is overkill. These discussions have > a natural tendency to go on forever, I agree. So let's try to keep to the > point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > wrote: >> >> BTW the new gerrit UI is a bit prettier: >> https://android-review.googlesource.com/#/q/status:open >> >> I'm a little concerned that we spend too much time on process and not >> enough time on improving VTK. But, I'll go with the consensus of the >> people who still work for a living. If the new process is too >> difficult for an old guy like me, I'll just spend my extra time with >> ITK. >> >> Bill >> >> >> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >> wrote: >> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >> > >> >>A fantasy feature for me would be that the system injects a step >> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >> >>reviewers for you based on reviewers "signing up" for reviewing certain >> >>modules, or perhaps based on recent-ish commits in the same files... >> > >> > That would be a great addition. I often don't know who to add as a >> > reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >> > person can use 'git log' and 'git blame' to get some guesses, and that could >> > be automated. Of course, sometimes that results in suggesting someone no >> > longer involved with VTK or the infamous 'VTK developers', but still it >> > would help to automate it. >> > >> > 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 >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> >> >> >> -- >> 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 > > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From berk.geveci at kitware.com Tue Aug 26 15:32:27 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 15:32:27 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Here is a summary that I came up with from the discussion so far. Does this look good? Requirements: - Branch / topic based workflow - Automated testing before merge (required to pass) - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) - Automatic notification on change - Ability to comment on the code (Web GUI preferred) - All reported bugs should be assessed and assigned Nice to have: - Tight integration with issue (bug) tracking and release process - Stakeholders for particular pieces identified / in the loop / easy or automatic assignment of reviewers - Ease of use - Incentive for reviewers (goal being encouraging more reviews) - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI - Lightweight proposal process for large changes - Way to track performance regression -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 15:43:34 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 15:43:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: +1 and Gerrit seems to support them all. On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci wrote: > Here is a summary that I came up with from the discussion so far. Does this > look good? > > Requirements: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > - All reported bugs should be assessed and assigned > > Nice to have: > > - Tight integration with issue (bug) tracking and release process > - Stakeholders for particular pieces identified / in the loop / easy or > automatic assignment of > reviewers > - Ease of use > - Incentive for reviewers (goal being encouraging more reviews) > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > - Lightweight proposal process for large changes > - Way to track performance regression > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:04:33 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:04:33 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: I disagree. Gerrit does not support any of the "nice to have"s in a straightforward way. Neither does vanilla Gerrit properly support "branch / topic based workflow" in a straightforward way. It supports a changeset based workflow and "branch / topic" based workflows have to be shoehorned into it if a "branch / topic" has more than 1 changeset. Also to support automated testing of branch tips, we would have to create custom scaffolding since vanilla Gerrit has no such concept. Gerrit, with a little help from cdash @ home does a decent job of the following: - Automated testing before merge (required to pass) - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) - Automatic notification on change - Ability to comment on the code (Web GUI preferred) It clearly doesn't do any of this: - Tight integration with issue (bug) tracking and release process - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI In my opinion, it does a very poor job of these: - Branch / topic based workflow - Ease of use The other requirements and nice-to-haves are independent of tools and can be achieved using whatever tool. However, Mantis is also not the easiest tool so replacing it is also a good idea. In my opinion, the biggest weaknesses of Github and Gitlab are: - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) They don't have a clear voting system and are based on more a general discussion workflow. We would have to create some guidelines on how to achieve these in those tools. For example, someone doing a pull request would have to add a comment mentioning potential reviewers with the @name syntax to "assign reviewers". The reviewers would have to use some previously agreed upon language to approve a topic in the discussion. Something like "Approved for merge". Github is far superior to Gerrit in these: - Branch / topic based workflow - Automated testing before merge (required to pass) - tight integration with Travis and demonstrated integration with cdash @ home through custom hooks - Automatic notification on change - much finer notification control - Ability to comment on the code (Web GUI preferred) - go check it out if you don't believe me - Tight integration with issue (bug) tracking and release process - Ease of use - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI - this is impossible in Gerrit even for a single changeset Best, -berk On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen wrote: > +1 and Gerrit seems to support them all. > > > On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci > wrote: > > Here is a summary that I came up with from the discussion so far. Does > this > > look good? > > > > Requirements: > > > > - Branch / topic based workflow > > - Automated testing before merge (required to pass) > > - Assign reviewers to topic > > - Review / approval before merge (required to pass) > > - Ability to go back to discussion leading to merge (audit trail) > > - Automatic notification on change > > - Ability to comment on the code (Web GUI preferred) > > - All reported bugs should be assessed and assigned > > > > Nice to have: > > > > - Tight integration with issue (bug) tracking and release process > > - Stakeholders for particular pieces identified / in the loop / easy or > > automatic assignment of > > reviewers > > - Ease of use > > - Incentive for reviewers (goal being encouraging more reviews) > > - Integration with Wiki > > - Easy documentation / Markdown /rST support > > - Easy way to generate single view of all changes in the Web GUI > > - Lightweight proposal process for large changes > > - Way to track performance regression > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Aug 26 16:05:22 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:05:22 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Agreed. I'll start some new threads on this. On Mon, Aug 25, 2014 at 9:17 PM, Bill Lorensen wrote: > Berk, > If the goal is to attract more developers then we need to understand why > we are not attracting them. We should not assume that changing our process > is a solution. I think the process discussion is a good one, but it may not > be the core issue. I suggest we start another thread to address the > developer issue. > > Bill > On Aug 25, 2014 7:47 PM, "Berk Geveci" wrote: > >> Hi Bill, >> >> The goal is not to have more process. It is to implement a workflow with >> fun-to-use tools such that we can continue to attract developers to VTK. >> VTK development is lively. We have done a lot of great stuff last year, >> both new development and maintenance, and we have great things coming next >> year. >> >> In my humble opinion, what we are doing poorly is attracting new >> developers. I think toolchain and workflow play a role in this. Not >> communicating well is another part. I'd like to attract more people to >> contribute code and more people to do reviews. Also, our bug tracker is >> collecting dust. Lots of bug reports are going in but it gets very little >> attention. I can't even remember when I looked at it last. >> >> Here are some statistics from openhub.net (website formerly known as >> ohloh): >> >> VTK: >> >> 30 Day Summary >> Jul 21 2014 ? Aug 20 2014 >> 152 Commits >> 19 Contributors >> >> 12 Month Summary >> Aug 20 2013 ? Aug 20 2014 >> 2393 Commits >> Down -965 (28%) from previous 12 months >> 64 Contributors >> Down -6 (8%) from previous 12 months >> >> Still a lot of commits but going down. >> >> So I'd like to see us slowly migrating towards tools that are more >> attractive and facilitate collaboration with the larger community. >> >> Frankly, I believe that our current set of tools get in the way. First of >> all, they all require creating accounts to do anything. An account for bug >> tracker, another for Gerrit, another for Wiki, another 2 for the mailing >> lists. We should have presence where people already hang out and don't have >> to create new accounts. Github, stackoverflow, Google+ etc. Second of all, >> they are all clunky at best. Usability does matter to people. Finally, >> there are a lot new resources available out there and we are not tapping >> into it as best as we can. We should be using Travis and Jenkins in >> addition to CDash and CDash @ Home for example. >> >> So I don't think that this conversation is overkill. These discussions >> have a natural tendency to go on forever, I agree. So let's try to keep to >> the point and make some decisions soon. >> >> Best, >> -berk >> >> >> >> >> >> >> On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen >> wrote: >> >>> BTW the new gerrit UI is a bit prettier: >>> https://android-review.googlesource.com/#/q/status:open >>> >>> I'm a little concerned that we spend too much time on process and not >>> enough time on improving VTK. But, I'll go with the consensus of the >>> people who still work for a living. If the new process is too >>> difficult for an old guy like me, I'll just spend my extra time with >>> ITK. >>> >>> Bill >>> >>> >>> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >>> wrote: >>> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >>> > >>> >>A fantasy feature for me would be that the system injects a step >>> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >>> >>reviewers for you based on reviewers "signing up" for reviewing certain >>> >>modules, or perhaps based on recent-ish commits in the same files... >>> > >>> > That would be a great addition. I often don't know who to add as a >>> reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >>> person can use 'git log' and 'git blame' to get some guesses, and that >>> could be automated. Of course, sometimes that results in suggesting >>> someone no longer involved with VTK or the infamous 'VTK developers', but >>> still it would help to automate it. >>> > >>> > 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 >>> > >>> > 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 bill.lorensen at gmail.com Tue Aug 26 16:09:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:09:13 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: I was addressing the first requirements list. Ease of use is subjective. On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: > I disagree. Gerrit does not support any of the "nice to have"s in a > straightforward way. Neither does vanilla Gerrit properly support "branch / > topic based workflow" in a straightforward way. It supports a changeset > based workflow and "branch / topic" based workflows have to be shoehorned > into it if a "branch / topic" has more than 1 changeset. Also to support > automated testing of branch tips, we would have to create custom scaffolding > since vanilla Gerrit has no such concept. > > Gerrit, with a little help from cdash @ home does a decent job of the > following: > > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > > It clearly doesn't do any of this: > > - Tight integration with issue (bug) tracking and release process > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > > In my opinion, it does a very poor job of these: > > - Branch / topic based workflow > - Ease of use > > The other requirements and nice-to-haves are independent of tools and can be > achieved using whatever tool. However, Mantis is also not the easiest tool > so replacing it is also a good idea. > > In my opinion, the biggest weaknesses of Github and Gitlab are: > > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > > They don't have a clear voting system and are based on more a general > discussion workflow. We would have to create some guidelines on how to > achieve these in those tools. For example, someone doing a pull request > would have to add a comment mentioning potential reviewers with the @name > syntax to "assign reviewers". The reviewers would have to use some > previously agreed upon language to approve a topic in the discussion. > Something like "Approved for merge". > > Github is far superior to Gerrit in these: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) - tight integration with > Travis and demonstrated integration with cdash @ home through custom hooks > - Automatic notification on change - much finer notification control > - Ability to comment on the code (Web GUI preferred) - go check it out if > you don't believe me > - Tight integration with issue (bug) tracking and release process > - Ease of use > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI - this is > impossible in Gerrit even for a single changeset > > Best, > -berk > > > > > > On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > wrote: >> >> +1 and Gerrit seems to support them all. >> >> >> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >> wrote: >> > Here is a summary that I came up with from the discussion so far. Does >> > this >> > look good? >> > >> > Requirements: >> > >> > - Branch / topic based workflow >> > - Automated testing before merge (required to pass) >> > - Assign reviewers to topic >> > - Review / approval before merge (required to pass) >> > - Ability to go back to discussion leading to merge (audit trail) >> > - Automatic notification on change >> > - Ability to comment on the code (Web GUI preferred) >> > - All reported bugs should be assessed and assigned >> > >> > Nice to have: >> > >> > - Tight integration with issue (bug) tracking and release process >> > - Stakeholders for particular pieces identified / in the loop / easy or >> > automatic assignment of >> > reviewers >> > - Ease of use >> > - Incentive for reviewers (goal being encouraging more reviews) >> > - Integration with Wiki >> > - Easy documentation / Markdown /rST support >> > - Easy way to generate single view of all changes in the Web GUI >> > - Lightweight proposal process for large changes >> > - Way to track performance regression >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > -- Unpaid intern in BillsBasement at noware dot com From aashish.chaudhary at kitware.com Tue Aug 26 16:09:09 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 26 Aug 2014 16:09:09 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: > I disagree. Gerrit does not support any of the "nice to have"s in a > straightforward way. Neither does vanilla Gerrit properly support "branch > / topic based workflow" in a straightforward way. It supports a changeset > based workflow and "branch / topic" based workflows have to be shoehorned > into it if a "branch / topic" has more than 1 changeset. Also to support > automated testing of branch tips, we would have to create custom > scaffolding since vanilla Gerrit has no such concept. > > Gerrit, with a little help from cdash @ home does a decent job of the > following: > > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > > It clearly doesn't do any of this: > > - Tight integration with issue (bug) tracking and release process > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > > In my opinion, it does a very poor job of these: > > - Branch / topic based workflow > - Ease of use > > The other requirements and nice-to-haves are independent of tools and can > be achieved using whatever tool. However, Mantis is also not the easiest > tool so replacing it is also a good idea. > > In my opinion, the biggest weaknesses of Github and Gitlab are: > > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > > They don't have a clear voting system and are based on more a general > discussion workflow. We would have to create some guidelines on how to > achieve these in those tools. For example, someone doing a pull request > would have to add a comment mentioning potential reviewers with the @name > syntax to "assign reviewers". The reviewers would have to use some > previously agreed upon language to approve a topic in the discussion. > Something like "Approved for merge". > > Github is far superior to Gerrit in these: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) - tight integration > with Travis and demonstrated integration with cdash @ home through custom > hooks > - Automatic notification on change - much finer notification control > - Ability to comment on the code (Web GUI preferred) - go check it out if > you don't believe me > - Tight integration with issue (bug) tracking and release process > - Ease of use > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI - this is > impossible in Gerrit even for a single changeset > > +1 for the nice assessment. I have a memory of similar thought from some other developers outside Kitware on this. Best, > -berk > > > > > > On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > wrote: > >> +1 and Gerrit seems to support them all. >> >> >> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >> wrote: >> > Here is a summary that I came up with from the discussion so far. Does >> this >> > look good? >> > >> > Requirements: >> > >> > - Branch / topic based workflow >> > - Automated testing before merge (required to pass) >> > - Assign reviewers to topic >> > - Review / approval before merge (required to pass) >> > - Ability to go back to discussion leading to merge (audit trail) >> > - Automatic notification on change >> > - Ability to comment on the code (Web GUI preferred) >> > - All reported bugs should be assessed and assigned >> > >> > Nice to have: >> > >> > - Tight integration with issue (bug) tracking and release process >> > - Stakeholders for particular pieces identified / in the loop / easy or >> > automatic assignment of >> > reviewers >> > - Ease of use >> > - Incentive for reviewers (goal being encouraging more reviews) >> > - Integration with Wiki >> > - Easy documentation / Markdown /rST support >> > - Easy way to generate single view of all changes in the Web GUI >> > - Lightweight proposal process for large changes >> > - Way to track performance regression >> > >> >> >> >> -- >> 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 > > 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 bill.lorensen at gmail.com Tue Aug 26 16:25:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:25:13 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Berk, I think we need to reach out to potential developers. Especially those outside of Kitware(and their paying customers) and the long term VTK developers outside Kitware. Those communities can adapt to anything. We need to focus on is how can we can attract new developers. In the past, new processes were adopted and adapted by Kitware, their customers and hard core VTK developers with very little input from the broader community of potential developers. ITK is going through the same issues but addressing the issues not through process change. They are looking at outreach and better documentation of the current process. Matt McCormick at Kitware has been leading this effort. I think there are lots of non-process improvements possible. But I don't have a silver bullet for attracting new developers. Perhaps VTK is too old school for today's developers. Stuck with an old architecture, old graphics architecture, old and complex languages. I honestly don't know what the root causes are. If we only include the old-timers in theses discussion then we will not attract a younger set of devleopers. Bill On Tue, Aug 26, 2014 at 4:09 PM, Bill Lorensen wrote: > I was addressing the first requirements list. Ease of use is subjective. > > On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: >> I disagree. Gerrit does not support any of the "nice to have"s in a >> straightforward way. Neither does vanilla Gerrit properly support "branch / >> topic based workflow" in a straightforward way. It supports a changeset >> based workflow and "branch / topic" based workflows have to be shoehorned >> into it if a "branch / topic" has more than 1 changeset. Also to support >> automated testing of branch tips, we would have to create custom scaffolding >> since vanilla Gerrit has no such concept. >> >> Gerrit, with a little help from cdash @ home does a decent job of the >> following: >> >> - Automated testing before merge (required to pass) >> - Assign reviewers to topic >> - Review / approval before merge (required to pass) >> - Ability to go back to discussion leading to merge (audit trail) >> - Automatic notification on change >> - Ability to comment on the code (Web GUI preferred) >> >> It clearly doesn't do any of this: >> >> - Tight integration with issue (bug) tracking and release process >> - Integration with Wiki >> - Easy documentation / Markdown /rST support >> - Easy way to generate single view of all changes in the Web GUI >> >> In my opinion, it does a very poor job of these: >> >> - Branch / topic based workflow >> - Ease of use >> >> The other requirements and nice-to-haves are independent of tools and can be >> achieved using whatever tool. However, Mantis is also not the easiest tool >> so replacing it is also a good idea. >> >> In my opinion, the biggest weaknesses of Github and Gitlab are: >> >> - Assign reviewers to topic >> - Review / approval before merge (required to pass) >> - Ability to go back to discussion leading to merge (audit trail) >> >> They don't have a clear voting system and are based on more a general >> discussion workflow. We would have to create some guidelines on how to >> achieve these in those tools. For example, someone doing a pull request >> would have to add a comment mentioning potential reviewers with the @name >> syntax to "assign reviewers". The reviewers would have to use some >> previously agreed upon language to approve a topic in the discussion. >> Something like "Approved for merge". >> >> Github is far superior to Gerrit in these: >> >> - Branch / topic based workflow >> - Automated testing before merge (required to pass) - tight integration with >> Travis and demonstrated integration with cdash @ home through custom hooks >> - Automatic notification on change - much finer notification control >> - Ability to comment on the code (Web GUI preferred) - go check it out if >> you don't believe me >> - Tight integration with issue (bug) tracking and release process >> - Ease of use >> - Integration with Wiki >> - Easy documentation / Markdown /rST support >> - Easy way to generate single view of all changes in the Web GUI - this is >> impossible in Gerrit even for a single changeset >> >> Best, >> -berk >> >> >> >> >> >> On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen >> wrote: >>> >>> +1 and Gerrit seems to support them all. >>> >>> >>> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >>> wrote: >>> > Here is a summary that I came up with from the discussion so far. Does >>> > this >>> > look good? >>> > >>> > Requirements: >>> > >>> > - Branch / topic based workflow >>> > - Automated testing before merge (required to pass) >>> > - Assign reviewers to topic >>> > - Review / approval before merge (required to pass) >>> > - Ability to go back to discussion leading to merge (audit trail) >>> > - Automatic notification on change >>> > - Ability to comment on the code (Web GUI preferred) >>> > - All reported bugs should be assessed and assigned >>> > >>> > Nice to have: >>> > >>> > - Tight integration with issue (bug) tracking and release process >>> > - Stakeholders for particular pieces identified / in the loop / easy or >>> > automatic assignment of >>> > reviewers >>> > - Ease of use >>> > - Incentive for reviewers (goal being encouraging more reviews) >>> > - Integration with Wiki >>> > - Easy documentation / Markdown /rST support >>> > - Easy way to generate single view of all changes in the Web GUI >>> > - Lightweight proposal process for large changes >>> > - Way to track performance regression >>> > >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:32:06 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:32:06 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton Message-ID: Hi folks, I propose a hack-a-ton to reduce the number of open issues in the bug tracker. It is like a yard that hasn't been mowed and weeded the whole summer. I propose a full day hack-a-ton. We can host some folks here at Kitware and others can join through a Google Hangout. I propose one in September. What do you think? Interested parties please send me an e-mail off the list with your preferred dates. This will have to be the first in a series. There are a lot of issues to go over. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Aug 26 16:35:36 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:35:36 -0400 Subject: [vtk-developers] Attracting next generation of developers Message-ID: Moved this discussion to a new thread. Berk, I think we need to reach out to potential developers. Especially those outside of Kitware(and their paying customers) and the long term VTK developers outside Kitware. Those communities can adapt to anything. We need to focus on is how can we can attract new developers. In the past, new processes were adopted and adapted by Kitware, their customers and hard core VTK developers with very little input from the broader community of potential developers. ITK is going through the same issues but addressing the issues not through process change. They are looking at outreach and better documentation of the current process. Matt McCormick at Kitware has been leading this effort. I think there are lots of non-process improvements possible. But I don't have a silver bullet for attracting new developers. Perhaps VTK is too old school for today's developers. Stuck with an old architecture, old graphics architecture, old and complex languages. I honestly don't know what the root causes are. If we only include the old-timers in theses discussion then we will not attract a younger set of devleopers. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 16:43:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:43:13 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: I will attend if possible. October is better for me, I will be away September 17-27. Mondays and Wednesdays are bad (golf). Sept 8,9,10 are bad. On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci wrote: > Hi folks, > > I propose a hack-a-ton to reduce the number of open issues in the bug > tracker. It is like a yard that hasn't been mowed and weeded the whole > summer. I propose a full day hack-a-ton. We can host some folks here at > Kitware and others can join through a Google Hangout. I propose one in > September. What do you think? Interested parties please send me an e-mail > off the list with your preferred dates. > > This will have to be the first in a series. There are a lot of issues to go > over. > > Best, > -berk > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:46:34 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:46:34 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Hi Bill, +10 to more outreach and better documentation of, well, everything. The language is probably an issue also. Let alone the C++ 11 issue, Python, Javascript, Java etc. are definitely taking away some developers. What I am most interested in is making some of the large group of users out there into VTK developers. This is something we have never done well. Even when we had bunch more users & developers. I think that this is an accessibility thing. Being more open to contributions. Doing more outreach. Doing more things like Google Summer of Code. Doing more hack-a-tons. Other ideas? Modernization is certainly part of it. Of course modernization while maintaining the right level of usability - not something ITK has done exceedingly well I have to say. We are making decent progress in this area. Where we lack most often is communicating all of the work going on. To me some of this comes back to workflow and tools by the way. Workflow and tools make communication and outreach easier or harder. I'll leave that part of the discussion to the other thread. What do other people think? What are people willing to do more of? Best, -berk On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci wrote: > Moved this discussion to a new thread. > > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 16:56:03 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:56:03 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Berk, I agree that users of VTK are untapped as potential devleopers. Perhaps a short, focused outreach email to the VTK users list is in order. Bill On Tue, Aug 26, 2014 at 4:46 PM, Berk Geveci wrote: > Hi Bill, > > +10 to more outreach and better documentation of, well, everything. > > The language is probably an issue also. Let alone the C++ 11 issue, Python, > Javascript, Java etc. are definitely taking away some developers. > > What I am most interested in is making some of the large group of users out > there into VTK developers. This is something we have never done well. Even > when we had bunch more users & developers. I think that this is an > accessibility thing. Being more open to contributions. Doing more outreach. > Doing more things like Google Summer of Code. Doing more hack-a-tons. Other > ideas? > > Modernization is certainly part of it. Of course modernization while > maintaining the right level of usability - not something ITK has done > exceedingly well I have to say. We are making decent progress in this area. > Where we lack most often is communicating all of the work going on. > > To me some of this comes back to workflow and tools by the way. Workflow and > tools make communication and outreach easier or harder. I'll leave that part > of the discussion to the other thread. > > What do other people think? What are people willing to do more of? > > Best, > -berk > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: >> >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> > -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Tue Aug 26 20:51:41 2014 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 26 Aug 2014 20:51:41 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Good stuff. Here are some random thoughts (besides some of the great stuff that's been mentioned before): + Provide potential community members an exciting purpose and/or a challenge. (See a list of crazy suggestions below.) I.e., paint a vision and get people excited due to social impact or technical challenge. + Define ways to contribute beyond just technical (i.e., lay out clear contribution paths), and recognize the community for these contributions. + Create "conferences" with invited speakers that get VTK developers and even application developers mixing together. Hold these at cool places with fun speakers and activities. The conferences could even have fun hackathon competitions addressing particular challenges / data. + Orgs like Kitware could invest some $ into awards, challenges, internships, etc. that are VTK-centric. + Here are crazy ideas for developing purposes/challenges: These need to capture the imagination and get people's creative juices flowing. These mini projects might be as simple as a single class/algorithm, or a complex as a subsystem. Maybe even consider something akin to ITK Applications which are satellite projects to leverage VTK infrastructure to do cool stuff. Lay out the challenges and recruit volunteers...if they are exciting enough it might attract talent and enthusiasm. -- Team with a data producer/application domain (like digital pathology, dermatolgy, environmental studies, microscopy, weather, sensor systems, etc.) and put together simple VTK-based tools for visualizing their data. These data could be associated with non-profits and/or research and represent significant social challenges. (I.e., help build a data-driven community with VTK playing a key role). -- Pick a technical challenge, like visualizing connectomics data, and with the help of the community use VTK as the core engine to build a simple application. The application might even be written in newer languages/environments (e.g., client-side). Other challenges might include mobile apps, etc. There's lots more but this is already long and crazy enough :-) W -- On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci wrote: > Moved this discussion to a new thread. > > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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 matt.mccormick at kitware.com Tue Aug 26 22:05:35 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 26 Aug 2014 22:05:35 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: +10 to the great comments by Bill, Berk, and Will. A few more thoughts to throw in the bucket: Another major factor to consider when attracting new developers is the cultivation of a sense of invested ownership. In connection with the review thread, it means that it is very important that reviews are encouraged from the community and that they are acknowledged. We do a good job of keeping track of Git patch authorship information -- we need to remember to keep track and promote review statistics, like in the visualization here [1] [2]. I disagree with the 'ITK is less usable' comment, not just because I am an ITK zealot ;-P. I think ITK is inherently as usable as VTK. It has a good software quality dashboard, like VTK, and the architecture and API, although orientated towards analysis instead of visualization, is at least modestly good like VTK. However, a person-oriented perception and experience of usability is more important than inherent, objective usability anyway. This subjective usability is highly influenced by an individual's background knowledge and the ability to acquire necessary knowledge. One strategy is to build bridges to familiar knowledge and provide documentation and training for the knowledge that is required. ITK now has a different API called SimpleITK [3], which is a better introduction for those unfamiliar with templates. Since the path to scientific programming most often involves coming from Python before C++, progress is being made to improve ITK wrapping. SimpleITK has great wrapping for Python and also other languages. The ITK Software Guide [4] is being updated, starting with updates and improvements on how to obtain and build the software. A new section was added recently on how to contribute. The excellent Wiki and Sphinx examples are also promoted and released with the code. Links are being added in the doxygen documentation to the book and example content. New code is required during review to have class and method documentation before merging [5]. These are examples of concrete steps that can be taken, but they could be improved, and there are other steps that could be taken. Another outstanding example that comes to mind is Berk's VTK NumPy interface blog posts [6], that both educate and bridge knowledge and technologies. I came across these customer reviews [1] on Amazon, and they have weighed on my mind. As a proud VTK and ITK community member, and as someone that has put sweat into a software book, they sting. But, they also inform the way to attract new developers and keep the ecosystem strong: provide basic, comprehensive documentation and create a fun, welcoming, merit-based community that has a big impact. Thanks for the long read, Matt [1] http://opensource.com/life/14/5/best-code-review-open-source-projects [2] http://thewtex.github.io/PropertiesOfCodeReviewSocialStructures/figures/itk_graph.html [3] http://simpleitk.org [4] http://itk.org/ITK/resources/software.html [5] http://review.source.kitware.com/#/c/11718/ [6] http://www.kitware.com/blog/home/post/723 [5] http://www.amazon.com/VTK-Users-Guide-Kitware/dp/1930934238/ref=sr_1_1?ie=UTF8&qid=1409085313&sr=8-1&keywords=vtk On Tue, Aug 26, 2014 at 8:51 PM, Will Schroeder wrote: > Good stuff. Here are some random thoughts (besides some of the great stuff > that's been mentioned before): > > + Provide potential community members an exciting purpose and/or a > challenge. (See a list of crazy suggestions below.) I.e., paint a vision and > get people excited due to social impact or technical challenge. > > + Define ways to contribute beyond just technical (i.e., lay out clear > contribution paths), and recognize the community for these contributions. > > + Create "conferences" with invited speakers that get VTK developers and > even application developers mixing together. Hold these at cool places with > fun speakers and activities. The conferences could even have fun hackathon > competitions addressing particular challenges / data. > > + Orgs like Kitware could invest some $ into awards, challenges, > internships, etc. that are VTK-centric. > > + Here are crazy ideas for developing purposes/challenges: These need to > capture the imagination and get people's creative juices flowing. These mini > projects might be as simple as a single class/algorithm, or a complex as a > subsystem. Maybe even consider something akin to ITK Applications which are > satellite projects to leverage VTK infrastructure to do cool stuff. Lay out > the challenges and recruit volunteers...if they are exciting enough it might > attract talent and enthusiasm. > > -- Team with a data producer/application domain (like digital pathology, > dermatolgy, environmental studies, microscopy, weather, sensor systems, > etc.) and put together simple VTK-based tools for visualizing their data. > These data could be associated with non-profits and/or research and > represent significant social challenges. (I.e., help build a data-driven > community with VTK playing a key role). > > -- Pick a technical challenge, like visualizing connectomics data, and with > the help of the community use VTK as the core engine to build a simple > application. The application might even be written in newer > languages/environments (e.g., client-side). Other challenges might include > mobile apps, etc. > > There's lots more but this is already long and crazy enough :-) > W > > > -- > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: >> >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > 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 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From biddisco at cscs.ch Wed Aug 27 03:16:43 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 07:16:43 +0000 Subject: [vtk-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR Message-ID: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Recompiling my Paraview plugins against the latest version, I find that many of the vtk::Keys I use frequently are gone. In order to handle my dynamic load balancing, I use the extent translators (particularly my own custom ones) continuously. Is there a replacement for this? 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 will.schroeder at kitware.com Wed Aug 27 07:25:19 2014 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 27 Aug 2014 07:25:19 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: A few more random thoughts: + Documentation: If we wanted to be really ambitious we would rewrite the VTK Textbook and User's Guide. Whatever we do, I'd like to see at least one "book" that is designed for interactivity from the ground up. An active publication that supports interactive book inserts where you can change view, parameters, etc. + Some of the most widely reused bits of VTK are "data" used to test or build examples. I've seen the cow, blade, combustor, etc. in technical papers, etc. We could build on this by gathering even more data and creating software/mini-apps around it. Even creating a series of reference benchmarks, etc. W On Tue, Aug 26, 2014 at 8:51 PM, Will Schroeder wrote: > Good stuff. Here are some random thoughts (besides some of the great stuff > that's been mentioned before): > > + Provide potential community members an exciting purpose and/or a > challenge. (See a list of crazy suggestions below.) I.e., paint a vision > and get people excited due to social impact or technical challenge. > > + Define ways to contribute beyond just technical (i.e., lay out clear > contribution paths), and recognize the community for these contributions. > > + Create "conferences" with invited speakers that get VTK developers and > even application developers mixing together. Hold these at cool places with > fun speakers and activities. The conferences could even have fun hackathon > competitions addressing particular challenges / data. > > + Orgs like Kitware could invest some $ into awards, challenges, > internships, etc. that are VTK-centric. > > + Here are crazy ideas for developing purposes/challenges: These need to > capture the imagination and get people's creative juices flowing. These > mini projects might be as simple as a single class/algorithm, or a complex > as a subsystem. Maybe even consider something akin to ITK Applications > which are satellite projects to leverage VTK infrastructure to do cool > stuff. Lay out the challenges and recruit volunteers...if they are exciting > enough it might attract talent and enthusiasm. > > -- Team with a data producer/application domain (like digital pathology, > dermatolgy, environmental studies, microscopy, weather, sensor systems, > etc.) and put together simple VTK-based tools for visualizing their data. > These data could be associated with non-profits and/or research and > represent significant social challenges. (I.e., help build a data-driven > community with VTK playing a key role). > > -- Pick a technical challenge, like visualizing connectomics data, and > with the help of the community use VTK as the core engine to build a simple > application. The application might even be written in newer > languages/environments (e.g., client-side). Other challenges might include > mobile apps, etc. > > There's lots more but this is already long and crazy enough :-) > W > > > -- > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: > >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > 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 berk.geveci at kitware.com Wed Aug 27 07:36:05 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 07:36:05 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Message-ID: Hi John, Check out: http://www.vtk.org/Wiki/VTK/Parallel_Pipeline Overall, load balancing should be much easier now. The reader can make arbitrary partitioning decisions but can still get requests from downstream about partitioning. Two main strategies: - Downstream send extent + piece requests, reader does its own partitioning based on these two - Downstream send specific extent requests to each rank (and no piece) The first one is appropriate to ParaView. This is much more robust and works through extract vois with subsampling etc. Something that never worked well in parallel. -berk On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. wrote: > Recompiling my Paraview plugins against the latest version, I find that > many of the vtk::Keys I use frequently are gone. > > > > In order to handle my dynamic load balancing, I use the extent translators > (particularly my own custom ones) continuously. > > > > Is there a replacement for this? > > > > 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 > > > > _______________________________________________ > Paraview-developers mailing list > Paraview-developers at paraview.org > http://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Aug 27 07:46:53 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 11:46:53 +0000 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Berk, OK. I see how the piece requests change, but I was using the extent translator to pass bounds information and (more importantly) a PKdTree (from Zoltan) downstream to the compositing engine to stop it from instantiating the D3 filter and performing a redundant and slow repartition when I enable transparency. My Zoltan partitioner used to add an extent translator (also containgin the KdTree) to the information in the pipeline, which the compositing code could detect and act appropriately (with some minor tweaks). Has the compositing code been enhanced in any way to make use of partitioning information that I can piggy-back for my needs? JB From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: 27 August 2014 13:36 To: Biddiscombe, John A. Cc: vtk-developers at vtk.org; paraview-developers at paraview.org Subject: Re: [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR Hi John, Check out: http://www.vtk.org/Wiki/VTK/Parallel_Pipeline Overall, load balancing should be much easier now. The reader can make arbitrary partitioning decisions but can still get requests from downstream about partitioning. Two main strategies: - Downstream send extent + piece requests, reader does its own partitioning based on these two - Downstream send specific extent requests to each rank (and no piece) The first one is appropriate to ParaView. This is much more robust and works through extract vois with subsampling etc. Something that never worked well in parallel. -berk On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. > wrote: Recompiling my Paraview plugins against the latest version, I find that many of the vtk::Keys I use frequently are gone. In order to handle my dynamic load balancing, I use the extent translators (particularly my own custom ones) continuously. Is there a replacement for this? 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 _______________________________________________ Paraview-developers mailing list Paraview-developers at paraview.org http://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Aug 27 07:57:52 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 11:57:52 +0000 Subject: [vtk-developers] Driving away your existing developers Message-ID: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> I deliberately put this into a different thread from the attracting new developers conversation. If I were kitware, I'd be concerned that developers like myself - who kitware couldn't care less about - are unable to contribute to the project, and as we leave, the next generation of interns and students are not being encouraged to join. Why? Because tools like the gerrit review system have made it so painful to get patches accepted that it is easier to simply maintain our own branches in private repos and not try to get them into master. Why? Because kitware has become a vtk/paraview dictator and pushes all its own patches and restructures the libraries and code whenever and however it wants. Those of us outside kitware who are not paying customers and who do not have time to chase down reviewers can't get anything in. I do not object to Kitware being a dictator, after all I can fork the project and do anything I want with it too, but making it so hard for anyone else to get in is hurting the project, and since our patches need to be maintained against a changing master where our branches get broken often, it gets harder and harder with time to get features accepted. Last year my intern and I created a large patch/branch with significant new features (2D transfer functions) which just sits in gerrit and will never make it into a release. In the old days, I'd have committed it, watched the dashboards, created tests and made sure it smoothly transitioned into a release (and others would have chipped in with fixes when something on the dashboard broke). I don't have the time to check it still builds against the changing master branches and I know no one else will either. Having to manage gerrit branches/reviews for separate VTK/ParaView patches is hard work and most of us don't have the time to do it (our job is actually not to maintain vtk/paraview/etc). We created a video and posted it with public calls for reviewers on the lists, but did we get any response? No. If we can't get reviewers from the general public, then we can't contribute. End of story. VTK http://review.source.kitware.com/#/t/3736/ PV http://review.source.kitware.com/#/t/3737/ 9 months. No reviews. Another sad thing is that although I have other nice plugins for paraview which provide useful features others could benefit from, they will never get into the main repo, Kitware will eventually create their own versions of them (c.f zoltan/metis partitoners), thus duplicating the work - and at the same time making our stuff redundant. Normally, I'd accept that I'm just a whiner and tell me to shut up. But I/We really made an effort to get help with the transfer function stuff and the evidence is that nobody cares - so my whining is justified. Kitware does do a great job of moving the project forward - it's a shame that outsiders can't. 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 rroemer at gmail.com Wed Aug 27 08:37:01 2014 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=C3=B6mer?=) Date: Wed, 27 Aug 2014 14:37:01 +0200 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: You are absolutely right, in most of your points. None if my commits were previewed by any native kitware developers. Its a pain to find the right previewers and after that none of them will do that job. So it is very hard for a new developer from outside the organization to get the right attention. This is frustrating... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Aug 27 08:54:26 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 27 Aug 2014 08:54:26 -0400 (EDT) Subject: [vtk-developers] Driving away your existing developers Message-ID: <8D1900D2AEFF48E-9F4-33CCB@webmail-vm086.sysops.aol.com> > If I were kitware, I?d be concerned that developers like myself - who > kitware couldn?t care less about - are unable to contribute to the > project, and as we leave, the next generation of interns and students > are not being encouraged to join. > ... > Normally, I?d accept that I?m just a whiner and tell me to shut up. > But I/We really made an effort to get help with the transfer function > stuff and the evidence is that nobody cares - so my whining is > justified. > ... > Kitware does do a great job of moving the project forward - it?s a > shame that outsiders can?t. This is a "hard to hear," but very valuable perspective from a long-time contributor to VTK and ParaView. Thanks, John, for expressing your opinion publicly, and clearly. Another way to phrase part of this discussion might be : "What would happen to these projects if Kitware abandoned them? How would the communities then re-organize...?" I've tried to stay active in CMake, VTK and ITK since leaving Kitware about 20 months ago, but it's been difficult to stay on top of it all. As John points out, for folks outside of Kitware, contributing is more of a "part time" endeavor that we have to squeeze in when we can. I'll continue to do so, because we use CMake, VTK and ITK to build our software, and I like to give back at least a little. John's topic in VTK is only one out of *126* open topics awaiting approval (or other dispensation) in gerrit, the oldest dating all the way back to September *2012*, a full two years ago. http://review.source.kitware.com/#/q/entity:topic%20status:open%20project:VTK,n,z In the other thread, about desired "workflow" and "tools," I expressed the desire to see reviewers assigned automatically when topics are submitted. That would help, but not totally solve the problem of an accumulating backlog of topics. Part of our workflow should be looking at the oldest topics in the queue, and deciding to abandon them at a certain point. After all, how many of the topics from more than 3 months ago would still merge successfully today even if approved...? An old topic / changeset with no reviewers should be a red flag that something's lacking in "the process." Unanswered emails on the list, unacknowledged bugs in the bug tracker, and unreviewed topics/changesets in gerrit are all issues that ought to be addressed to prevent driving existing people away and to help new contributors feel welcomed on a project. David C. From david.gobbi at gmail.com Wed Aug 27 09:13:19 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 07:13:19 -0600 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: The most important thing is to engage the community. Developers will be very forgiving about the process as long as you keep them engaged. Community engagement requires: - Responsive communication. You don't need to always have the answer, you just need to not be silent. - Dedication. Share your dreams and show that you care about the future. Help your employees to do the same. - Transparency. Lay out the roadmap for all to see. Summarize important development meetings on the wiki. You got this NIH grant, so far I see OpenGL2 and community outreach as aims, but for the most part I'm in the dark about your plans. When developers are kept in the dark, they feel like they're being shut out. There are several potential pools of developers: 1) VTK developers that currently hoard their code instead of contributing it back to VTK. This is a huge pool of capable developers. As John indicated in his email from this morning, process is important but the key is simple: when these people want to contribute, don't flat-out ignore them! 2) Companies for whom VTK is a core tool, and who therefore have a stake in its development. Really, these are the same as (1) except that they often have more resources. 3) Big grants and collaborations, where large chunks of development is done outside of Kitware. These undoubtedly help to increase the pool of developers, so a the question is, how to keep those developers engaged and ensure that good results are fed back into VTK. 4) Young hot-shots who see VTK as just the thing they need for their new project. For them, having a "Cool and Hip" VTK is important, but the three bullet points at the top of this email are much, much more important. I've got tons more that I could ramble on about, but it's time for breakfast (it's still 7am here in western Canada). - David From berk.geveci at kitware.com Wed Aug 27 09:10:46 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 09:10:46 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: You are both absolutely right. The review process is broken when it comes to accepting patches from the community. It is broken in 3 ways: 1. As Kitware, we haven't put the right attention to reviewing contributed code from top down (i.e. me and other managers using project resources and asking developers to review contributed work). Even when we have specific projects under which this can be done, we favor developing new code to reviewing contributions. 2. As individual contributors to VTK and ParaView, many of the Kitware developers are focused on their primary goals. We haven't built the open source community spirit as well as we can. Part of this needs to be done by the larger community with encouragement by senior folks (not just ones at Kitware). 3. As others pointed out, there is not enough emphasis and encouragement in reviewing code by the larger community. My code would languish in Gerrit if I didn't have the ability to walk to someone next door and ask them to review it please. David Gobbi and others had suggestions on how to encourage the larger community to be more involved in reviewing. My opinion is that this all boils down to making people feel ownership for VTK rather than seeing it as a tool that needs to be patched as necessary for other work or some project goal (deliver x,y and z and you are done). This is not something I can easily force people to do nor is it a top down thing. I am doing my best by encouraging more community engagement, removing barriers from tools and setting an example by contributing in various ways. I'd like to hear suggestions on how to achieve this and what I can do towards this. One idea: more community hack-a-tons. I just sent out a suggestion for addressing issues in the bug tracker. Why not have another one for reviewing code? One final note. Everyone please keep in mind that while there are quite a lot of contributors to VTK, certain parts of it are developed by only a few people. Core pipeline: I am it at this point. Rendering: by next year, it will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at Kitware does anything with imaging filters. We update them when we make changes to the pipeline or data model but that's it. So some of those are maintained and developed by others or they are some orphaned. This can only be addressed by either encouraging new (or existing) developers to take ownership or by removing those components all together. My 2 cents. -berk On Wed, Aug 27, 2014 at 8:37 AM, Ronald R?mer wrote: > You are absolutely right, in most of your points. None if my commits were > previewed by any native kitware developers. Its a pain to find the right > previewers and after that none of them will do that job. So it is very hard > for a new developer from outside the organization to get the right > attention. This is frustrating... > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.harris at kitware.com Wed Aug 27 09:32:40 2014 From: chris.harris at kitware.com (Chris Harris) Date: Wed, 27 Aug 2014 09:32:40 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Here is my two cents/pence, I apologize if I am rehashing already discussed topics, I am a little late to the party. In no particular order ? - The development process should be enforced and supported by the review tool rather than people and documents. No one wants to be the ?enforcer? and documents often go unread. - GitHub/GitLab PR workflow works well with projects that have a ?benevolent dictator? and relatively small teams, I?m not sure it scales so well when you have a larger number of people with merge access where more coordination is necessary. - As well as indicating approval, it is just as important to be able indicate that you don?t want something to be merged, for example a work in progress branch or you don?t agree with how something should be implemented. The likes of GitHub/GitLab tend to have an all or nothing approach here, if I have merge privileges I can merge any PR in the project and no one can stop me short of removing my privileges. - In my opinion no one should have push access to master, all merging should be done automatically. My understanding with GitHub/GitLab is if you can merge in the UI you can push to master. I have been in projects where developers have push to master by mistake, it happens. - Long running topic with lots of commits should be the exception rather than the rule. Topics that have a lot of commits are hard to review, in my opinion these could be treated differently as the usefulness of the review tool breaks down here. For VTK the mean number of changes in a topic: 1.88 and the median number of changes in a topic: 1. This to me indicates that topic branch support is a nice to have rather than a necessity. - I feel that as a part of the open source community we should be using open source tools where possible. So I would add being open source as a nice to have. - Finally I think supporting PR from GitHub is important, it's a familiar workflow for many developers. However, this doesn't mean that GitHub has to be our review tool. Integration is possible with other tools, for example Gerrit has a GitHub plugin. I have contributed to projects that use SVN through GitHub PRs :-) Regards, Chris On Tue, Aug 26, 2014 at 4:25 PM, Bill Lorensen wrote: > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > On Tue, Aug 26, 2014 at 4:09 PM, Bill Lorensen > wrote: > > I was addressing the first requirements list. Ease of use is subjective. > > > > On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci > wrote: > >> I disagree. Gerrit does not support any of the "nice to have"s in a > >> straightforward way. Neither does vanilla Gerrit properly support > "branch / > >> topic based workflow" in a straightforward way. It supports a changeset > >> based workflow and "branch / topic" based workflows have to be > shoehorned > >> into it if a "branch / topic" has more than 1 changeset. Also to support > >> automated testing of branch tips, we would have to create custom > scaffolding > >> since vanilla Gerrit has no such concept. > >> > >> Gerrit, with a little help from cdash @ home does a decent job of the > >> following: > >> > >> - Automated testing before merge (required to pass) > >> - Assign reviewers to topic > >> - Review / approval before merge (required to pass) > >> - Ability to go back to discussion leading to merge (audit trail) > >> - Automatic notification on change > >> - Ability to comment on the code (Web GUI preferred) > >> > >> It clearly doesn't do any of this: > >> > >> - Tight integration with issue (bug) tracking and release process > >> - Integration with Wiki > >> - Easy documentation / Markdown /rST support > >> - Easy way to generate single view of all changes in the Web GUI > >> > >> In my opinion, it does a very poor job of these: > >> > >> - Branch / topic based workflow > >> - Ease of use > >> > >> The other requirements and nice-to-haves are independent of tools and > can be > >> achieved using whatever tool. However, Mantis is also not the easiest > tool > >> so replacing it is also a good idea. > >> > >> In my opinion, the biggest weaknesses of Github and Gitlab are: > >> > >> - Assign reviewers to topic > >> - Review / approval before merge (required to pass) > >> - Ability to go back to discussion leading to merge (audit trail) > >> > >> They don't have a clear voting system and are based on more a general > >> discussion workflow. We would have to create some guidelines on how to > >> achieve these in those tools. For example, someone doing a pull request > >> would have to add a comment mentioning potential reviewers with the > @name > >> syntax to "assign reviewers". The reviewers would have to use some > >> previously agreed upon language to approve a topic in the discussion. > >> Something like "Approved for merge". > >> > >> Github is far superior to Gerrit in these: > >> > >> - Branch / topic based workflow > >> - Automated testing before merge (required to pass) - tight integration > with > >> Travis and demonstrated integration with cdash @ home through custom > hooks > >> - Automatic notification on change - much finer notification control > >> - Ability to comment on the code (Web GUI preferred) - go check it out > if > >> you don't believe me > >> - Tight integration with issue (bug) tracking and release process > >> - Ease of use > >> - Integration with Wiki > >> - Easy documentation / Markdown /rST support > >> - Easy way to generate single view of all changes in the Web GUI - this > is > >> impossible in Gerrit even for a single changeset > >> > >> Best, > >> -berk > >> > >> > >> > >> > >> > >> On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > > >> wrote: > >>> > >>> +1 and Gerrit seems to support them all. > >>> > >>> > >>> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci > >>> wrote: > >>> > Here is a summary that I came up with from the discussion so far. > Does > >>> > this > >>> > look good? > >>> > > >>> > Requirements: > >>> > > >>> > - Branch / topic based workflow > >>> > - Automated testing before merge (required to pass) > >>> > - Assign reviewers to topic > >>> > - Review / approval before merge (required to pass) > >>> > - Ability to go back to discussion leading to merge (audit trail) > >>> > - Automatic notification on change > >>> > - Ability to comment on the code (Web GUI preferred) > >>> > - All reported bugs should be assessed and assigned > >>> > > >>> > Nice to have: > >>> > > >>> > - Tight integration with issue (bug) tracking and release process > >>> > - Stakeholders for particular pieces identified / in the loop / easy > or > >>> > automatic assignment of > >>> > reviewers > >>> > - Ease of use > >>> > - Incentive for reviewers (goal being encouraging more reviews) > >>> > - Integration with Wiki > >>> > - Easy documentation / Markdown /rST support > >>> > - Easy way to generate single view of all changes in the Web GUI > >>> > - Lightweight proposal process for large changes > >>> > - Way to track performance regression > >>> > > >>> > >>> > >>> > >>> -- > >>> Unpaid intern in BillsBasement at noware dot com > >> > >> > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > > > > -- > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wes.turner at kitware.com Wed Aug 27 10:02:21 2014 From: wes.turner at kitware.com (Wes Turner) Date: Wed, 27 Aug 2014 10:02:21 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 9:13 AM, David Gobbi wrote: > The most important thing is to engage the community. Developers will > be very forgiving about the process as long as you keep them engaged. > > Community engagement requires: > > - Responsive communication. You don't need to always have the answer, > you just need to not be silent. > > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. > > You got this NIH grant, so far I see OpenGL2 and community outreach > as aims, but for the most part I'm in the dark about your plans. When > developers are kept in the dark, they feel like they're being shut out. > > > There are several potential pools of developers: > > 1) VTK developers that currently hoard their code instead of > contributing it back to VTK. This is a huge pool of capable > developers. As John indicated in his email from this morning, > process is important but the key is simple: when these people > want to contribute, don't flat-out ignore them! > +1 Make contributing simple and be responsive. - Wes > 2) Companies for whom VTK is a core tool, and who therefore have a > stake in its development. Really, these are the same as (1) except > that they often have more resources. > > 3) Big grants and collaborations, where large chunks of development is > done outside of Kitware. These undoubtedly help to increase the pool > of developers, so a the question is, how to keep those developers > engaged and ensure that good results are fed back into VTK. > > 4) Young hot-shots who see VTK as just the thing they need for their > new project. For them, having a "Cool and Hip" VTK is important, but > the three bullet points at the top of this email are much, much more > important. > > I've got tons more that I could ramble on about, but it's time for > breakfast (it's still 7am here in western Canada). > > - David > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Wesley D. Turner, Ph.D. Kitware, Inc. Technical Leader 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4920 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Aug 27 10:20:07 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 27 Aug 2014 10:20:07 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <53FCBB58.5090405@gmail.com> Message-ID: <20140827142007.GA15572@megas.kitwarein.com> On Wed, Aug 27, 2014 at 09:32:40 -0400, Chris Harris wrote: > ? The development process should be enforced and supported by the review tool > rather than people and documents. No one wants to be the ??enforcer? and > documents often go unread. Agreed. > ? GitHub/GitLab PR workflow works well with projects that have a ?benevolent > dictator? and relatively small teams, I?m not sure it scales so well when > you have a larger number of people with merge access where more > coordination is necessary. The Rust repository juggles lots of incoming branches, but has a single bot do all of the merges based on comments from "blessed" contributors. > ? As well as indicating approval, it is just as important to be able indicate > that you don?t want something to be merged, for example a work in progress > branch or you don?t agree with how something should be implemented. The > likes of GitHub/GitLab tend to have an all or nothing approach here, if I > have merge privileges I can merge any PR in the project and no one can stop > me short of removing my privileges. I've usually put WIP in my topic names for works-in-progress that I'd like comments on before I dig a hole too deep on some feature. If maintainers pull it while it still has that tag then they're not really doing their job, IMO. If we had a mergebot, then it could just refuse anything with and active "WIP" tag (however it ends up being specified). > ? In my opinion no one should have push access to master, all merging should > be done automatically. My understanding with GitHub/GitLab is if you can > merge in the UI you can push to master. I have been in projects where > developers have push to master by mistake, it happens. +1 > ? Long running topic with lots of commits should be the exception rather than > the rule. Topics that have a lot of commits are hard to review, in my > opinion these could be treated differently as the usefulness of the review > tool breaks down here. For VTK the mean number of changes in a topic: 1.88 > and the median number of changes in a topic: 1. This to me indicates that > topic branch support is a nice to have rather than a necessity. Sure, the majority are single-commits, but there's no way that all branches belong in just one commit and that those branches are treated as second-rate citizens in review. I view it as an absolute necessity to support multi-commit branches gracefully. In fact, it is the larger branches that need *more* review tool support and ease-of-use than the small branches because they are already inherently hard to review. One thing I *really* want is a "full branch diff" view from the tool so that I can see the branch in its entirety. When I need to do this now, I pull from Gerrit, but it's a pain because getting the commits from there is unnecessarily complex (the ref names it uses aren't fetched by default). > ? I feel that as a part of the open source community we should be using open > source tools where possible. So I would add being open source as a nice to > have. +1 > ? Finally I think supporting PR from GitHub is important, it's a familiar > workflow for many developers. However, this doesn't mean that GitHub has to > be our review tool. Integration is possible with other tools, for example > Gerrit has a GitHub plugin. I have contributed to projects that use SVN > through GitHub PRs :-) A bot could pull PRs into whatever we end up using automatically with the web hooks Github provides. --Ben From david.gobbi at gmail.com Wed Aug 27 10:40:41 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 08:40:41 -0600 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 8:02 AM, Wes Turner wrote: > > +1 Make contributing simple and be responsive. I should add that it's absolutely fine to have a high rejection rate. If a submission is rejected, the developer might try again. If a submission is ignored, they won't! (Unless they're persistent SOBs like me.) - David From dlrdave at aol.com Wed Aug 27 10:47:17 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 27 Aug 2014 10:47:17 -0400 (EDT) Subject: [vtk-developers] Attracting next generation of developers Message-ID: <8D1901CEE92E699-FC0-31807@webmail-m218.sysops.aol.com> >> >> +1 Make contributing simple and be responsive. > I should add that it's absolutely fine to have a high rejection rate. > If a submission is rejected, the developer might try again. If a > submission is ignored, they won't! (Unless they're persistent SOBs > like me.) Definitely! People learn from rejection, it wakes them up and sometimes even inspires them, ... especially persistent SOBs. Think of it more as "suggesting refinement" than rejecting... :-) David C. From david.gobbi at gmail.com Wed Aug 27 12:00:21 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 10:00:21 -0600 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci wrote: > One final note. Everyone please keep in mind that while there are quite a > lot of contributors to VTK, certain parts of it are developed by only a few > people. Core pipeline: I am it at this point. Rendering: by next year, it > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at > Kitware does anything with imaging filters. We update them when we make > changes to the pipeline or data model but that's it. So some of those are > maintained and developed by others or they are some orphaned. This can only > be addressed by either encouraging new (or existing) developers to take > ownership or by removing those components all together. I have tons of plans for the VTK imaging classes, but unfortunately I have almost no resources so progress is slow. Some examples: 1) Improving both the API and the performance for multi-threading. Last year I worked with an intern to improve load sharing. Never had time to finish, because it wasn't the intern's main project. 2) Basic linear image registration in VTK. I've finished it and it's very robust (been using it for years), but refactoring so that it can be contributed to VTK is an evening/weekend project and hence is moving slowly. 3) Better image iterators. I have a nice image iterator that iterates over arbitrary shapes and also provides coordinate info while it iterates. I'd love to develop this further and contribute it, and I'd especially love to wrap it, but it's out in left field as far as my day job goes. 4) Better filters for going back and forth between image data and polydata. Lots of people use my vtkPolyDataToImageStencil filter, but it has faults and I know exactly how to fix them, but I'll have to wait until it comes up as a priority for one of my work projects. 5) Finally, a better overall structure for the imaging pipeline, focused on the basics: a) scalar operation "functors" that can be plugged into filters b) interpolators, which I've already committed c) good image "region" descriptors (like my vtkImageStencilData) d) connectivity & morphological operations, I've got lots of un-committed stuff e) a replacement for the lousy vtkImageMathematics filter Ideally I should write out a big roadmap (the items mentioned above is just a fraction of the total), but it would be depressing because so much of it feels like it's nothing more than a pipe dream. And, as Berk mentioned, there isn't anyone in Kitware for me to directly work with on this stuff. And all the other VTK imaging developers outside of Kitware are content to keep their work to themselves, without contributing back to the VTK core. Or at least, that's the way it looks from my vantage point. - David From pieper at isomics.com Wed Aug 27 17:03:55 2014 From: pieper at isomics.com (Steve Pieper) Date: Wed, 27 Aug 2014 17:03:55 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: I would love to see more of your excellent work, David, and I'd want to make use of it, but I'd argue that at least some of it, perhaps registration, may not belong in VTK itself. Speaking for myself from my experience in the slicer project, I can say that we end up putting a lot of our functionality in classes that don't belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of which adds functionality that is independent of our slicer application, but adds a layer of dependencies that nobody would want to see in VTK itself. On my wishlist for VTK would be a better way for new developers to contribute their work so that it's easily usable by others but doesn't have to pass the gauntlet of reviews and comments and be in VTK before it is easily usable by others. I'd like to see an experience more like npm for node, where anyone can publish a domain-specific set of code and other people can use it or not as they see fit. Node itself remains small and it rarely changes, but the ecosystem is quite vibrant. It allows a lot of diversity, but amazing interoperability and reusability. In slicer we have something similar now with the Extension Catalog, where developers can offer code (either pure VTK or things that work at the VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform nightly builds and test it on all platforms, this code is in reasonable shape for other people to draw from, either in slicer or elsewhere. Typically these extensions are in github repositories, so they have their own wikis, issue lists, pull requests, etc. We hope that slicer itself actually gets smaller over time and generally doesn't need to change very much or very often. I would love to see something similar in VTK proper. Right now VTK has a lot of modules that are quite domain specific, such as Chemistry and Geovis which I do not envision using myself. I would have preferred to see that code exist in a different repository where people who needed it would have the option of including it in their superbuild process. Others could safely ignore it. I would even argue that half (or more) of the current modules don't really belong in the 'actual' VTK and should be moved out. If there were a good place to put some of this kind of code it might also be a good spot for libraries like vtkITK and vtkTeem. In fact I would argue that if it weren't actually in VTK's repository, a project like vtkChemistry might attract more participants and have more features (but I can't prove that of course). So basically I'd say that VTK is currently too big and should get smaller, while the community is too small and should get bigger. -Steve On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi wrote: > On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci > wrote: > > > One final note. Everyone please keep in mind that while there are quite a > > lot of contributors to VTK, certain parts of it are developed by only a > few > > people. Core pipeline: I am it at this point. Rendering: by next year, it > > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis > team at > > Kitware does anything with imaging filters. We update them when we make > > changes to the pipeline or data model but that's it. So some of those are > > maintained and developed by others or they are some orphaned. This can > only > > be addressed by either encouraging new (or existing) developers to take > > ownership or by removing those components all together. > > I have tons of plans for the VTK imaging classes, but unfortunately I have > almost no resources so progress is slow. Some examples: > > 1) Improving both the API and the performance for multi-threading. > Last year I worked with an intern to improve load sharing. Never had > time to finish, because it wasn't the intern's main project. > > 2) Basic linear image registration in VTK. I've finished it and it's > very robust (been using it for years), but refactoring so that it can > be contributed to VTK is an evening/weekend project and hence is > moving slowly. > > 3) Better image iterators. I have a nice image iterator that iterates > over arbitrary shapes and also provides coordinate info while it > iterates. I'd love to develop this further and contribute it, and I'd > especially love to wrap it, but it's out in left field as far as my > day job goes. > > 4) Better filters for going back and forth between image data and > polydata. Lots of people use my vtkPolyDataToImageStencil filter, > but it has faults and I know exactly how to fix them, but I'll have to > wait until it comes up as a priority for one of my work projects. > > 5) Finally, a better overall structure for the imaging pipeline, > focused on the basics: > a) scalar operation "functors" that can be plugged into filters > b) interpolators, which I've already committed > c) good image "region" descriptors (like my vtkImageStencilData) > d) connectivity & morphological operations, I've got lots of un-committed > stuff > e) a replacement for the lousy vtkImageMathematics filter > > Ideally I should write out a big roadmap (the items mentioned above > is just a fraction of the total), but it would be depressing because so > much of it feels like it's nothing more than a pipe dream. > > And, as Berk mentioned, there isn't anyone in Kitware for me to > directly work with on this stuff. And all the other VTK imaging > developers outside of Kitware are content to keep their work to > themselves, without contributing back to the VTK core. Or at least, > that's the way it looks from my vantage point. > > - David > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Aug 27 18:03:06 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 18:03:06 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Message-ID: Hi John, Good news. It is now much easier to propagate meta-data and requests in VTK now. (Don't give me a hard time about not communicating this. I am working on my issues). All you need is a subclass of a vtkInformationKey that overrides CopyDefaultInformation(), probably to copy itself. Look at vtkEnsembleSource and vtkInformationDataObjectMetaDataKey to see an example. In fact, if your kd tree is a vtkDataObject subclass, you can use that key class to define a custom key like vtkEnsembleSource. No more need for keys to copy silliness. There is also support for adding arbitrary request objects without changing executives. Look at vtkInformationIntegerRequestKey to see an example. You need a key subclass that overrides CopyDefaultInformation(), NeedToExecute(), StoreMetaData() for that. I will write a blog with details in the near future. Best, -berk On Wed, Aug 27, 2014 at 7:46 AM, Biddiscombe, John A. wrote: > Berk, > > > > OK. I see how the piece requests change, but I was using the extent > translator to pass bounds information and (more importantly) a PKdTree > (from Zoltan) downstream to the compositing engine to stop it from > instantiating the D3 filter and performing a redundant and slow repartition > when I enable transparency. My Zoltan partitioner used to add an extent > translator (also containgin the KdTree) to the information in the pipeline, > which the compositing code could detect and act appropriately (with some > minor tweaks). > > > > Has the compositing code been enhanced in any way to make use of > partitioning information that I can piggy-back for my needs? > > > > JB > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* 27 August 2014 13:36 > *To:* Biddiscombe, John A. > *Cc:* vtk-developers at vtk.org; paraview-developers at paraview.org > *Subject:* Re: [Paraview-developers] > vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR > > > > Hi John, > > > > Check out: > > > > http://www.vtk.org/Wiki/VTK/Parallel_Pipeline > > > > Overall, load balancing should be much easier now. The reader can make > arbitrary partitioning decisions but can still get requests from downstream > about partitioning. Two main strategies: > > > > - Downstream send extent + piece requests, reader does its own > partitioning based on these two > > - Downstream send specific extent requests to each rank (and no piece) > > > > The first one is appropriate to ParaView. > > > > This is much more robust and works through extract vois with subsampling > etc. Something that never worked well in parallel. > > > > -berk > > > > On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. > wrote: > > Recompiling my Paraview plugins against the latest version, I find that > many of the vtk::Keys I use frequently are gone. > > > > In order to handle my dynamic load balancing, I use the extent translators > (particularly my own custom ones) continuously. > > > > Is there a replacement for this? > > > > 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 > > > > > _______________________________________________ > Paraview-developers mailing list > Paraview-developers at paraview.org > http://public.kitware.com/mailman/listinfo/paraview-developers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 Wed Aug 27 20:58:48 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 27 Aug 2014 20:58:48 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: ITK's remote module mechanism is a great way to add domain specific modules. I agree with Steve that vtk proper should get smaller. On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: > I would love to see more of your excellent work, David, and I'd want to > make use of it, but I'd argue that at least some of it, perhaps > registration, may not belong in VTK itself. > > Speaking for myself from my experience in the slicer project, I can say > that we end up putting a lot of our functionality in classes that don't > belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of > which adds functionality that is independent of our slicer application, but > adds a layer of dependencies that nobody would want to see in VTK itself. > > On my wishlist for VTK would be a better way for new developers to > contribute their work so that it's easily usable by others but doesn't have > to pass the gauntlet of reviews and comments and be in VTK before it is > easily usable by others. I'd like to see an experience more like npm for > node, where anyone can publish a domain-specific set of code and other > people can use it or not as they see fit. Node itself remains small and it > rarely changes, but the ecosystem is quite vibrant. It allows a lot of > diversity, but amazing interoperability and reusability. > > In slicer we have something similar now with the Extension Catalog, where > developers can offer code (either pure VTK or things that work at the > VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform > nightly builds and test it on all platforms, this code is in reasonable > shape for other people to draw from, either in slicer or elsewhere. > Typically these extensions are in github repositories, so they have their > own wikis, issue lists, pull requests, etc. We hope that slicer itself > actually gets smaller over time and generally doesn't need to change very > much or very often. > > I would love to see something similar in VTK proper. Right now VTK has a > lot of modules that are quite domain specific, such as Chemistry and Geovis > which I do not envision using myself. I would have preferred to see that > code exist in a different repository where people who needed it would have > the option of including it in their superbuild process. Others could > safely ignore it. I would even argue that half (or more) of the current > modules don't really belong in the 'actual' VTK and should be moved out. > If there were a good place to put some of this kind of code it might also > be a good spot for libraries like vtkITK and vtkTeem. In fact I would > argue that if it weren't actually in VTK's repository, a project like > vtkChemistry might attract more participants and have more features (but I > can't prove that of course). > > So basically I'd say that VTK is currently too big and should get smaller, > while the community is too small and should get bigger. > > -Steve > > > On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi > wrote: > >> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >> wrote: >> >> > One final note. Everyone please keep in mind that while there are quite >> a >> > lot of contributors to VTK, certain parts of it are developed by only a >> few >> > people. Core pipeline: I am it at this point. Rendering: by next year, >> it >> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >> team at >> > Kitware does anything with imaging filters. We update them when we make >> > changes to the pipeline or data model but that's it. So some of those >> are >> > maintained and developed by others or they are some orphaned. This can >> only >> > be addressed by either encouraging new (or existing) developers to take >> > ownership or by removing those components all together. >> >> I have tons of plans for the VTK imaging classes, but unfortunately I have >> almost no resources so progress is slow. Some examples: >> >> 1) Improving both the API and the performance for multi-threading. >> Last year I worked with an intern to improve load sharing. Never had >> time to finish, because it wasn't the intern's main project. >> >> 2) Basic linear image registration in VTK. I've finished it and it's >> very robust (been using it for years), but refactoring so that it can >> be contributed to VTK is an evening/weekend project and hence is >> moving slowly. >> >> 3) Better image iterators. I have a nice image iterator that iterates >> over arbitrary shapes and also provides coordinate info while it >> iterates. I'd love to develop this further and contribute it, and I'd >> especially love to wrap it, but it's out in left field as far as my >> day job goes. >> >> 4) Better filters for going back and forth between image data and >> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >> but it has faults and I know exactly how to fix them, but I'll have to >> wait until it comes up as a priority for one of my work projects. >> >> 5) Finally, a better overall structure for the imaging pipeline, >> focused on the basics: >> a) scalar operation "functors" that can be plugged into filters >> b) interpolators, which I've already committed >> c) good image "region" descriptors (like my vtkImageStencilData) >> d) connectivity & morphological operations, I've got lots of >> un-committed stuff >> e) a replacement for the lousy vtkImageMathematics filter >> >> Ideally I should write out a big roadmap (the items mentioned above >> is just a fraction of the total), but it would be depressing because so >> much of it feels like it's nothing more than a pipe dream. >> >> And, as Berk mentioned, there isn't anyone in Kitware for me to >> directly work with on this stuff. And all the other VTK imaging >> developers outside of Kitware are content to keep their work to >> themselves, without contributing back to the VTK core. Or at least, >> that's the way it looks from my vantage point. >> >> - David >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 Aug 28 10:10:42 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Thu, 28 Aug 2014 14:10:42 +0000 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> Berk Thanks once more for the info. Question : The class I want to pass downstream is a vtkObject and not a vtkDataObject, so .. There are informationDataObject and InformationDataObjectMetaData keys, but there are not informationObject and InformationObjectMetaData keys, but since DataObject is a type of Object, would anything be adversely affected if I were to change them to InformationObject->InformationObjectMetaData and provide a GetObject and GetDataObject interface to return the type contained? Adding two new classes seems wasteful when they actually do the same thing internally. Do the informationDataObject and metadata key classes need to specialized as different from Object and ObjectMetaData? (other than just for naming purposes) ta JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Aug 28 10:16:49 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:16:49 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> Message-ID: I have no objection whatsoever to changing it to be a subclass of vtkInformationObjectBaseKey and renaming it as such. It should work but please run the ensemble source test to make sure. -berk On Thu, Aug 28, 2014 at 10:10 AM, Biddiscombe, John A. wrote: > Berk > > > > Thanks once more for the info. > > > > Question : > > > > The class I want to pass downstream is a vtkObject and not a > vtkDataObject, so .. > > > > There are > > informationDataObject and InformationDataObjectMetaData keys, but there > are not > > informationObject and InformationObjectMetaData keys, > > > > but since DataObject is a type of Object, would anything be adversely > affected if I were to change them to > > InformationObject->InformationObjectMetaData > > > > and provide a GetObject and GetDataObject interface to return the type > contained? Adding two new classes seems wasteful when they actually do the > same thing internally. > > > > Do the informationDataObject and metadata key classes need to specialized > as different from Object and ObjectMetaData? (other than just for naming > purposes) > > > > ta > > > > JB > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 28 10:18:22 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 28 Aug 2014 10:18:22 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: <20140828141822.216694143@mail.rogue-research.com> On Tue, 26 Aug 2014 16:43:13 -0400, Bill Lorensen said: >I will attend if possible. October is better for me, I will be away >September 17-27. Mondays and Wednesdays are bad (golf). Sept 8,9,10 >are bad. I will also attend if possible. Always fun to meet up in person. October also better for me. I'm leaving for vacation for the next two weeks tonight (BTW: email support at rogue if one of our buildbots needs kicking) and will be busy catching up the week I'm back. 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 berk.geveci at kitware.com Thu Aug 28 10:21:39 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:21:39 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: Several people indicated a preference for October. How about October 2nd? Best, -berk On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci wrote: > Hi folks, > > I propose a hack-a-ton to reduce the number of open issues in the bug > tracker. It is like a yard that hasn't been mowed and weeded the whole > summer. I propose a full day hack-a-ton. We can host some folks here at > Kitware and others can join through a Google Hangout. I propose one in > September. What do you think? Interested parties please send me an e-mail > off the list with your preferred dates. > > This will have to be the first in a series. There are a lot of issues to > go over. > > Best, > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Aug 28 10:44:58 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:44:58 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: > I agree with Steve that vtk proper should get smaller. I agree with the spirit of this. In fact, I get very exciting thinking about how this would work and how nice and useful the infrastructure would be. However, I don't think it is very feasible to use such a mechanism to pull out parts of current VTK. It is a maintenance issue. We have had years of experience of maintaining tightly coupled projects that are in separate repositories (VTK and ParaView). And it is not easy. It requires team dedicated to maintaining each separately, with separate dashboard architecture, git branches, code review processes etc. If we had, say, 10 small projects that tightly depended on VTK and was developed by roughly the same team, there would be a significant overhead to development and maintenance. What would the development workflow be to keep these in sync? Having the "remote" modules depend on a release version of VTK is not tightly coupled enough and would hamper development significantly. So we would have to manage some version dependency mechanism that would be at best hard. I can see making a handful of modules that hardly change external. Or some modules that change more regularly but depend less on changes to core features. Some of the IO modules with external dependencies, maybe VTK Web, some filtering module such as Matlab, R, Reebgraph etc. But is it really worth the trouble? It would shrink VTK slightly but would make testing, integration etc. harder for everyone. I would rather focus on implementing this for new projects / modules. Specially those that are developed in a way that's less coupled with VTK. Some Slicer code could be organized this way for example. Slicer depends on a release version of VTK and has its own testing infrastructure so it should be easy. Things like ITK-VTK adapters could probably be organized the same way. What would the mechanism for indicating version dependencies, whether a remote module is tested regularly and things like that? Best, -berk On Wed, Aug 27, 2014 at 8:58 PM, Bill Lorensen wrote: > ITK's remote module mechanism is a great way to add domain specific > modules. I agree with Steve that vtk proper should get smaller. > On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: > >> I would love to see more of your excellent work, David, and I'd want to >> make use of it, but I'd argue that at least some of it, perhaps >> registration, may not belong in VTK itself. >> >> Speaking for myself from my experience in the slicer project, I can say >> that we end up putting a lot of our functionality in classes that don't >> belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of >> which adds functionality that is independent of our slicer application, but >> adds a layer of dependencies that nobody would want to see in VTK itself. >> >> On my wishlist for VTK would be a better way for new developers to >> contribute their work so that it's easily usable by others but doesn't have >> to pass the gauntlet of reviews and comments and be in VTK before it is >> easily usable by others. I'd like to see an experience more like npm for >> node, where anyone can publish a domain-specific set of code and other >> people can use it or not as they see fit. Node itself remains small and it >> rarely changes, but the ecosystem is quite vibrant. It allows a lot of >> diversity, but amazing interoperability and reusability. >> >> In slicer we have something similar now with the Extension Catalog, where >> developers can offer code (either pure VTK or things that work at the >> VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform >> nightly builds and test it on all platforms, this code is in reasonable >> shape for other people to draw from, either in slicer or elsewhere. >> Typically these extensions are in github repositories, so they have their >> own wikis, issue lists, pull requests, etc. We hope that slicer itself >> actually gets smaller over time and generally doesn't need to change very >> much or very often. >> >> I would love to see something similar in VTK proper. Right now VTK has a >> lot of modules that are quite domain specific, such as Chemistry and Geovis >> which I do not envision using myself. I would have preferred to see that >> code exist in a different repository where people who needed it would have >> the option of including it in their superbuild process. Others could >> safely ignore it. I would even argue that half (or more) of the current >> modules don't really belong in the 'actual' VTK and should be moved out. >> If there were a good place to put some of this kind of code it might also >> be a good spot for libraries like vtkITK and vtkTeem. In fact I would >> argue that if it weren't actually in VTK's repository, a project like >> vtkChemistry might attract more participants and have more features (but I >> can't prove that of course). >> >> So basically I'd say that VTK is currently too big and should get >> smaller, while the community is too small and should get bigger. >> >> -Steve >> >> >> On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi >> wrote: >> >>> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >>> wrote: >>> >>> > One final note. Everyone please keep in mind that while there are >>> quite a >>> > lot of contributors to VTK, certain parts of it are developed by only >>> a few >>> > people. Core pipeline: I am it at this point. Rendering: by next year, >>> it >>> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >>> team at >>> > Kitware does anything with imaging filters. We update them when we make >>> > changes to the pipeline or data model but that's it. So some of those >>> are >>> > maintained and developed by others or they are some orphaned. This can >>> only >>> > be addressed by either encouraging new (or existing) developers to take >>> > ownership or by removing those components all together. >>> >>> I have tons of plans for the VTK imaging classes, but unfortunately I >>> have >>> almost no resources so progress is slow. Some examples: >>> >>> 1) Improving both the API and the performance for multi-threading. >>> Last year I worked with an intern to improve load sharing. Never had >>> time to finish, because it wasn't the intern's main project. >>> >>> 2) Basic linear image registration in VTK. I've finished it and it's >>> very robust (been using it for years), but refactoring so that it can >>> be contributed to VTK is an evening/weekend project and hence is >>> moving slowly. >>> >>> 3) Better image iterators. I have a nice image iterator that iterates >>> over arbitrary shapes and also provides coordinate info while it >>> iterates. I'd love to develop this further and contribute it, and I'd >>> especially love to wrap it, but it's out in left field as far as my >>> day job goes. >>> >>> 4) Better filters for going back and forth between image data and >>> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >>> but it has faults and I know exactly how to fix them, but I'll have to >>> wait until it comes up as a priority for one of my work projects. >>> >>> 5) Finally, a better overall structure for the imaging pipeline, >>> focused on the basics: >>> a) scalar operation "functors" that can be plugged into filters >>> b) interpolators, which I've already committed >>> c) good image "region" descriptors (like my vtkImageStencilData) >>> d) connectivity & morphological operations, I've got lots of >>> un-committed stuff >>> e) a replacement for the lousy vtkImageMathematics filter >>> >>> Ideally I should write out a big roadmap (the items mentioned above >>> is just a fraction of the total), but it would be depressing because so >>> much of it feels like it's nothing more than a pipe dream. >>> >>> And, as Berk mentioned, there isn't anyone in Kitware for me to >>> directly work with on this stuff. And all the other VTK imaging >>> developers outside of Kitware are content to keep their work to >>> themselves, without contributing back to the VTK core. Or at least, >>> that's the way it looks from my vantage point. >>> >>> - David >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> The information in this e-mail is intended only for the person to whom >>> it is >>> addressed. If you believe this e-mail was sent to you in error and the >>> e-mail >>> contains patient information, please contact the Partners Compliance >>> HelpLine at >>> http://www.partners.org/complianceline . If the e-mail was sent to you >>> in error >>> but does not contain patient information, please contact the sender and >>> properly >>> dispose of the e-mail. >>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 28 11:07:49 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 28 Aug 2014 11:07:49 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: <20140828150749.1061007759@mail.rogue-research.com> Hi all, Alas I haven't had the time with my impending vacation to add some thoughts, but I'll say broadly that I agree with what most of you are saying. One thing I don't think anyone has said, maybe because I'm the only one that thinks this way :), is that I find it hard to follow what changes are happening in VTK. Certainly reading the lists and kitware blog helps, but I think it would be cool to have 2 additional things: 1) a 'commits' email list, like other projects. Where you get an email for every merge into master. 2) a weekly summary like this: Which obviously would take time and effort on someone's part, but would be cool. :) You kitware guys probably chat at lunch about what others are doing, but from outside it's not always so clear. 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 pieper at isomics.com Thu Aug 28 11:17:51 2014 From: pieper at isomics.com (Steve Pieper) Date: Thu, 28 Aug 2014 11:17:51 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: Hi Berk - This is a helpful discussion and I like that we are thinking through the implications before making any decisions. I also think we should look at development communities that work well, and try to learn from those examples. That's why I suggested node and npm as an ecosystem that seems to really work in my experience. There's lots of sophisticated code that works well together and people use it to create software that is of similar complexity to VTK and ParaView. There are well established testing and version control methodologies. The core is very small and stable, but there are packages for just about anything you can imagine. The community also attracts contributions from all the types David mentioned (companies, academics, and sharp independent developers). Do people have other community models that they think work well and would be worth studying? Or perhaps we could also learn from failed/failing communities, so as not to repeat their mistakes. -Steve On Thu, Aug 28, 2014 at 10:44 AM, Berk Geveci wrote: > > I agree with Steve that vtk proper should get smaller. > > I agree with the spirit of this. In fact, I get very exciting thinking > about how this would work and how nice and > useful the infrastructure would be. However, I don't think it is very > feasible to use such a mechanism to > pull out parts of current VTK. It is a maintenance issue. We have had > years of experience of maintaining > tightly coupled projects that are in separate repositories (VTK and > ParaView). And it is not easy. It requires > team dedicated to maintaining each separately, with separate dashboard > architecture, git branches, code > review processes etc. If we had, say, 10 small projects that tightly > depended on VTK and was developed > by roughly the same team, there would be a significant overhead to > development and maintenance. What > would the development workflow be to keep these in sync? Having the > "remote" modules depend on a release > version of VTK is not tightly coupled enough and would hamper development > significantly. So we would > have to manage some version dependency mechanism that would be at best > hard. > > I can see making a handful of modules that hardly change external. Or some > modules that change more > regularly but depend less on changes to core features. Some of the IO > modules with external dependencies, > maybe VTK Web, some filtering module such as Matlab, R, Reebgraph etc. But > is it really worth the trouble? > It would shrink VTK slightly but would make testing, integration etc. > harder for everyone. > > I would rather focus on implementing this for new projects / modules. > Specially those that are developed > in a way that's less coupled with VTK. Some Slicer code could be organized > this way for example. Slicer > depends on a release version of VTK and has its own testing infrastructure > so it should be easy. Things > like ITK-VTK adapters could probably be organized the same way. > > What would the mechanism for indicating version dependencies, whether a > remote module is tested > regularly and things like that? > > Best, > -berk > > > On Wed, Aug 27, 2014 at 8:58 PM, Bill Lorensen > wrote: > >> ITK's remote module mechanism is a great way to add domain specific >> modules. I agree with Steve that vtk proper should get smaller. >> On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: >> >>> I would love to see more of your excellent work, David, and I'd want to >>> make use of it, but I'd argue that at least some of it, perhaps >>> registration, may not belong in VTK itself. >>> >>> Speaking for myself from my experience in the slicer project, I can say >>> that we end up putting a lot of our functionality in classes that don't >>> belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of >>> which adds functionality that is independent of our slicer application, but >>> adds a layer of dependencies that nobody would want to see in VTK itself. >>> >>> On my wishlist for VTK would be a better way for new developers to >>> contribute their work so that it's easily usable by others but doesn't have >>> to pass the gauntlet of reviews and comments and be in VTK before it is >>> easily usable by others. I'd like to see an experience more like npm for >>> node, where anyone can publish a domain-specific set of code and other >>> people can use it or not as they see fit. Node itself remains small and it >>> rarely changes, but the ecosystem is quite vibrant. It allows a lot of >>> diversity, but amazing interoperability and reusability. >>> >>> In slicer we have something similar now with the Extension Catalog, >>> where developers can offer code (either pure VTK or things that work at the >>> VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform >>> nightly builds and test it on all platforms, this code is in reasonable >>> shape for other people to draw from, either in slicer or elsewhere. >>> Typically these extensions are in github repositories, so they have their >>> own wikis, issue lists, pull requests, etc. We hope that slicer itself >>> actually gets smaller over time and generally doesn't need to change very >>> much or very often. >>> >>> I would love to see something similar in VTK proper. Right now VTK has >>> a lot of modules that are quite domain specific, such as Chemistry and >>> Geovis which I do not envision using myself. I would have preferred to see >>> that code exist in a different repository where people who needed it would >>> have the option of including it in their superbuild process. Others could >>> safely ignore it. I would even argue that half (or more) of the current >>> modules don't really belong in the 'actual' VTK and should be moved out. >>> If there were a good place to put some of this kind of code it might also >>> be a good spot for libraries like vtkITK and vtkTeem. In fact I would >>> argue that if it weren't actually in VTK's repository, a project like >>> vtkChemistry might attract more participants and have more features (but I >>> can't prove that of course). >>> >>> So basically I'd say that VTK is currently too big and should get >>> smaller, while the community is too small and should get bigger. >>> >>> -Steve >>> >>> >>> On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi >>> wrote: >>> >>>> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >>>> wrote: >>>> >>>> > One final note. Everyone please keep in mind that while there are >>>> quite a >>>> > lot of contributors to VTK, certain parts of it are developed by only >>>> a few >>>> > people. Core pipeline: I am it at this point. Rendering: by next >>>> year, it >>>> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >>>> team at >>>> > Kitware does anything with imaging filters. We update them when we >>>> make >>>> > changes to the pipeline or data model but that's it. So some of those >>>> are >>>> > maintained and developed by others or they are some orphaned. This >>>> can only >>>> > be addressed by either encouraging new (or existing) developers to >>>> take >>>> > ownership or by removing those components all together. >>>> >>>> I have tons of plans for the VTK imaging classes, but unfortunately I >>>> have >>>> almost no resources so progress is slow. Some examples: >>>> >>>> 1) Improving both the API and the performance for multi-threading. >>>> Last year I worked with an intern to improve load sharing. Never had >>>> time to finish, because it wasn't the intern's main project. >>>> >>>> 2) Basic linear image registration in VTK. I've finished it and it's >>>> very robust (been using it for years), but refactoring so that it can >>>> be contributed to VTK is an evening/weekend project and hence is >>>> moving slowly. >>>> >>>> 3) Better image iterators. I have a nice image iterator that iterates >>>> over arbitrary shapes and also provides coordinate info while it >>>> iterates. I'd love to develop this further and contribute it, and I'd >>>> especially love to wrap it, but it's out in left field as far as my >>>> day job goes. >>>> >>>> 4) Better filters for going back and forth between image data and >>>> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >>>> but it has faults and I know exactly how to fix them, but I'll have to >>>> wait until it comes up as a priority for one of my work projects. >>>> >>>> 5) Finally, a better overall structure for the imaging pipeline, >>>> focused on the basics: >>>> a) scalar operation "functors" that can be plugged into filters >>>> b) interpolators, which I've already committed >>>> c) good image "region" descriptors (like my vtkImageStencilData) >>>> d) connectivity & morphological operations, I've got lots of >>>> un-committed stuff >>>> e) a replacement for the lousy vtkImageMathematics filter >>>> >>>> Ideally I should write out a big roadmap (the items mentioned above >>>> is just a fraction of the total), but it would be depressing because so >>>> much of it feels like it's nothing more than a pipe dream. >>>> >>>> And, as Berk mentioned, there isn't anyone in Kitware for me to >>>> directly work with on this stuff. And all the other VTK imaging >>>> developers outside of Kitware are content to keep their work to >>>> themselves, without contributing back to the VTK core. Or at least, >>>> that's the way it looks from my vantage point. >>>> >>>> - David >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>>> The information in this e-mail is intended only for the person to whom >>>> it is >>>> addressed. If you believe this e-mail was sent to you in error and the >>>> e-mail >>>> contains patient information, please contact the Partners Compliance >>>> HelpLine at >>>> http://www.partners.org/complianceline . If the e-mail was sent to you >>>> in error >>>> but does not contain patient information, please contact the sender and >>>> properly >>>> dispose of the e-mail. >>>> >>>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> 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 > > 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 Thu Aug 28 12:07:10 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 28 Aug 2014 12:07:10 -0400 (EDT) Subject: [vtk-developers] Driving away your existing developers In-Reply-To: <20140828150749.1061007759@mail.rogue-research.com> References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> <20140828150749.1061007759@mail.rogue-research.com> Message-ID: <8D190F141E2A9DF-1A54-39495@webmail-m205.sysops.aol.com> There is this: http://vtk.org/gitweb?p=VTK.git;a=shortlog;h=refs/heads/master Available via rss here: http://vtk.org/gitweb?p=VTK.git;a=rss;h=refs/heads/master Better than an email list in my opinion... D From berk.geveci at kitware.com Thu Aug 28 13:49:36 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 13:49:36 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Hi David and other, > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. Here is my attempt to respond to these: http://www.kitware.com/blog/home/post/728 -berk On Wed, Aug 27, 2014 at 9:13 AM, David Gobbi wrote: > The most important thing is to engage the community. Developers will > be very forgiving about the process as long as you keep them engaged. > > Community engagement requires: > > - Responsive communication. You don't need to always have the answer, > you just need to not be silent. > > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. > > You got this NIH grant, so far I see OpenGL2 and community outreach > as aims, but for the most part I'm in the dark about your plans. When > developers are kept in the dark, they feel like they're being shut out. > > > There are several potential pools of developers: > > 1) VTK developers that currently hoard their code instead of > contributing it back to VTK. This is a huge pool of capable > developers. As John indicated in his email from this morning, > process is important but the key is simple: when these people > want to contribute, don't flat-out ignore them! > > 2) Companies for whom VTK is a core tool, and who therefore have a > stake in its development. Really, these are the same as (1) except > that they often have more resources. > > 3) Big grants and collaborations, where large chunks of development is > done outside of Kitware. These undoubtedly help to increase the pool > of developers, so a the question is, how to keep those developers > engaged and ensure that good results are fed back into VTK. > > 4) Young hot-shots who see VTK as just the thing they need for their > new project. For them, having a "Cool and Hip" VTK is important, but > the three bullet points at the top of this email are much, much more > important. > > I've got tons more that I could ramble on about, but it's time for > breakfast (it's still 7am here in western Canada). > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Thu Aug 28 16:59:54 2014 From: wascott at sandia.gov (Scott, W Alan) Date: Thu, 28 Aug 2014 20:59:54 +0000 Subject: [vtk-developers] [EXTERNAL] Re: Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: Berk/all, I have read this thread with interest, and have been impressed with how open and honest everyone has been. We have a problem, we discuss the problem, we find fixes for the problem. After discussing these issues with my local team, one comment came up over and over again. I realize that the VTK workflow and this thread are different than ParaView, but since my experience is with ParaView, I will comment accordingly. Further, I realize that the two projects have different needs, but I think the following comments still apply. Although the current procedures do have issues slowing down community contributions, they also have strengths. This is true for ParaView, and I assume for VTK. I have been doing a lot of testing of ParaView for the upcoming 4.2 release, and ParaView is amazingly ?clean? at this point. GUI?s are clear, workflows are simple (or as simple as can be), lots of stuff gets tested in the dashboards, and everything just works (well, most things just work). I am now somewhat surprised when I find bugs, as opposed to the past, where I was surprised when I didn?t. Numerous years ago, before development was reviewed before moving it into head, it was always a crap shoot when updating. Now, it is rare that Master isn?t in a state that is release candidate quality. And I believe that Master should always be in a state that is release candidate quality. My executive summary is this: as we move forward, let?s make sure we don?t lose the processes and controls that have given us the quality products we currently have. my $0.02. Alan From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Wednesday, August 27, 2014 7:11 AM To: Ronald R?mer Cc: VTK Developers Subject: [EXTERNAL] Re: [vtk-developers] Driving away your existing developers You are both absolutely right. The review process is broken when it comes to accepting patches from the community. It is broken in 3 ways: 1. As Kitware, we haven't put the right attention to reviewing contributed code from top down (i.e. me and other managers using project resources and asking developers to review contributed work). Even when we have specific projects under which this can be done, we favor developing new code to reviewing contributions. 2. As individual contributors to VTK and ParaView, many of the Kitware developers are focused on their primary goals. We haven't built the open source community spirit as well as we can. Part of this needs to be done by the larger community with encouragement by senior folks (not just ones at Kitware). 3. As others pointed out, there is not enough emphasis and encouragement in reviewing code by the larger community. My code would languish in Gerrit if I didn't have the ability to walk to someone next door and ask them to review it please. David Gobbi and others had suggestions on how to encourage the larger community to be more involved in reviewing. My opinion is that this all boils down to making people feel ownership for VTK rather than seeing it as a tool that needs to be patched as necessary for other work or some project goal (deliver x,y and z and you are done). This is not something I can easily force people to do nor is it a top down thing. I am doing my best by encouraging more community engagement, removing barriers from tools and setting an example by contributing in various ways. I'd like to hear suggestions on how to achieve this and what I can do towards this. One idea: more community hack-a-tons. I just sent out a suggestion for addressing issues in the bug tracker. Why not have another one for reviewing code? One final note. Everyone please keep in mind that while there are quite a lot of contributors to VTK, certain parts of it are developed by only a few people. Core pipeline: I am it at this point. Rendering: by next year, it will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at Kitware does anything with imaging filters. We update them when we make changes to the pipeline or data model but that's it. So some of those are maintained and developed by others or they are some orphaned. This can only be addressed by either encouraging new (or existing) developers to take ownership or by removing those components all together. My 2 cents. -berk On Wed, Aug 27, 2014 at 8:37 AM, Ronald R?mer > wrote: You are absolutely right, in most of your points. None if my commits were previewed by any native kitware developers. Its a pain to find the right previewers and after that none of them will do that job. So it is very hard for a new developer from outside the organization to get the right attention. This is frustrating... _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html 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 Aug 28 18:09:21 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 29 Aug 2014 08:09:21 +1000 Subject: [vtk-developers] Driving away your existing developers Message-ID: It is nice to see all this discussion happening, so keeping the discussion at the higher level. A) When the VTK ARB was set up there were a group of people nominated for topic leads. See: http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process maybe this list needs updating. This feeds into B), below, as these people are often very busy and should be alerted to relevant submissions. B) A while back I asked a question about whether it is possible to get from gerrit regular management reports, see: http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html and I got no replies. I saw that David Cole did a simple enquiry much like I have done. Unless I am really missing something fundamental, and I have searched the web, this does not happen easily with gerrit. I have taken the approach of being notified of all submissions to gerrit and then helping where possible. Obviously on some days this results in a lot of e-mails. What would be really useful would be management style status reports such as: 1) The number of reviews with no reviewers. 2) The number of reviews approved but not submitted. 3) The number of reviews awaiting approval. If these are generated, say monthly, then we should get a good overall picture of what is happening and for example in the case of 1) notify the submitter that reviewers are needed. One of the issues here is that often people submitting new code or updates often do not noiminate reviewers - I guess they either do not read all the documentation for the process or they feel uncomfortable about nominating someone unknown to them. I think putting a process in place like this should help a lot particularly with respect to the issues Dabid Gobbi raised. This would also help community engagement as submitters will know that their submissions are being looked at. So this feeds into Will's comments too. C) As to the complexity of VTK ... hey it is a library and it is complex! It supports many compilers, has many contributions from many different people, has a rigorous somewhat old-fashioned C++ programming style. However it has survived for over 20 years ... so it must be working. Personally I think discussion about moving classes such as vtkITK, vtkTeem, and vtkMRML out may be a bit early, particularly when we must remember that VTK underpins ParaView, and their users need/want(?) this functionality. One other worrying aspect (to me) is the slowness of the migration to VTK 6.x - it seems from the users group lots of people are still using older versions such as VTK 5.8. These people need to be encouraged to upgrade to 6. I know that Steve Piper had issues with Slicer, but, correct me if I am wrong, I did see something along the lines that these issues are largely resolved. D) VTK is not broken and it has many years of life yet! I think if we can implement better management reporting, move people to VTK 6.1 and always encourage migration to the most recent version, then this will reduce the burden on Kitware and also encourage newer developers because the responsiveness will be there. There is always exciting stuff happening in VTK e.g OpenGL2, Numpy, Android stuff etc. We need to get this message out that there is great stuff happening and everybody can help. Anyway this is my take on it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Fri Aug 1 01:22:01 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 1 Aug 2014 15:22:01 +1000 Subject: [vtk-developers] More VTK Wiki Examples questions Message-ID: Hi David, I just compiled and ran the example on my laptop (Windows 8.1, VS 2013) using a recent checkout of the VTK Master, and I get the same image as the test image. The data file I used is the one that is downloaded into the build directory, namely the one in: \ExternalData\Testing\Data\Infovis When I build VTK, it downloads any test files and the corresponding *.md5-stamp file into this directory. Maybe VTK_DATA_STORE needs to be set to point to the ExternalData directory for CTest to work correctly. It is definitely set when CMake runs on the VTK source. I hope this helps. Regards Andrew > ---------- Forwarded message ---------- > From: David Cole > To: vtk-developers at vtk.org, jeff.baumes at kitware.com, > bill.lorensen at gmail.com > Cc: > Date: Thu, 31 Jul 2014 14:11:09 -0400 (EDT) > Subject: [vtk-developers] More VTK Wiki Examples questions > This example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader > > gets an "fsm.gml" data file from "somewhere" (but *NOT* VTKData) and uses > it when running the VTK Wiki Examples dashboard on my machine. > > > This example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/TreeMapView > > apparently depends on VTKData, which I do not have, so the test fails on > my machine. > > > On the wiki page itself, there's a note saying we should generate an > example tree map instead of loading from a data file: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/TreeMapView > > > So... we can fix the failing test by making the TreeMapView's data files > available (as fsm.gml is already available) to my dashboard build.... or by > modifying the TreeMapView example to use some generated data. Which is > easier? > > I'm not sure how to do either myself -- I'm hoping Bill L. can easily add > some data for this example, or Jeff Baumes can point me to how to generate > an example TreeMap easily... > > > Thanks, > David C. > > > > > ---------- Forwarded message ---------- > From: David Cole > To: vtk-developers at vtk.org, jeff.baumes at kitware.com > Cc: > Date: Thu, 31 Jul 2014 14:20:57 -0400 (EDT) > Subject: [vtk-developers] InfoVis graph visualization question: > vtkGraphLayoutView with a "Simple 2D" layout strategy > This VTK wiki example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/InfoVis/XGMLReader > > Yields this different rendering test failure on my dashboard machine: > http://open.cdash.org/testDetails.php?test=271695203&build=3430870 > > The graph structure looks the same, and the visual is roughly equivalent, > but the expected image clearly shows a perfectly square glyph at each graph > node. In my test image, the graph nodes look like they vary from circle to > square to polygons in between... > > What determines the shape of the node glyph in a vtkGraphLayoutView with a > "Simple 2D" layout strategy? And would the shape difference account > entirely for the slight offset and angle between expected image and test > image...? > > > Thanks, > David C. > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Fri Aug 1 07:38:53 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 07:38:53 -0400 (EDT) Subject: [vtk-developers] More VTK Wiki Examples questions Message-ID: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> > I just compiled and ran the example on my laptop (Windows 8.1, VS > 2013) using a recent checkout of the VTK Master, and I get the same > image as the test image. Thanks -- after reading through http://www.vtk.org/Wiki/VTK/Examples/Instructions/ForAdministrators it appears that in order to run a test that requires data files as arguments, the git repo for the wiki examples at git://gitorious.org/vtkwikiexamples/wikiexamples.git has to be modified manually. I'll see if I can add a topic that adds the required data files for the TreeMap example so the test can pass on my machine. If I can get it to work, I'll push it and send a pull request to Bill L. to get it into the official repo. Thanks for checking and verifying that it works for you. D From dlrdave at aol.com Fri Aug 1 07:46:00 2014 From: dlrdave at aol.com (David Cole) Date: Fri, 1 Aug 2014 07:46:00 -0400 (EDT) Subject: [vtk-developers] More VTK Wiki Examples questions In-Reply-To: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> References: <8D17B944E3186C9-BD0-1586A@webmail-d258.sysops.aol.com> Message-ID: <8D17B954CDDF024-BD0-158A3@webmail-d258.sysops.aol.com> My main point with this thread is: The TreeMap example test passes *accidentally* on Bill's dashboards because he has an old VTKData lying around and the example is picking up the input files from VTKData... On my dashboard machine without any VTKData directories anywhere, the test fails because the Wiki Examples git repo does not contain these data files yet. D From dave.demarle at kitware.com Tue Aug 5 13:47:43 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 5 Aug 2014 13:47:43 -0400 Subject: [vtk-developers] any volunteers for vtk qt examples issues? Message-ID: We turned kargad continuous's examples ON on 4/21, and ever since then it has had 8 qt related build errors. Any volunteers out there to fix them? http://open.cdash.org/viewBuildError.php?buildid=3302083 I'm all for updating the qt we use there if that is all it takes. 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 andrew.amaclean at gmail.com Tue Aug 5 19:32:03 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 6 Aug 2014 09:32:03 +1000 Subject: [vtk-developers] VTK Code Formatting Styles Message-ID: Has anyone got: 1) A code style for QT Creator for VTK? 2) Also one for Eclipse? If so would they be willing to share/put up in the Wiki? Thanks Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Aug 5 20:59:02 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 5 Aug 2014 20:59:02 -0400 Subject: [vtk-developers] [vtkusers] VTK Code Formatting Styles In-Reply-To: References: Message-ID: I use this for eclipse. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 5, 2014 at 7:32 PM, Andrew Maclean wrote: > Has anyone got: > 1) A code style for QT Creator for VTK? > 2) Also one for Eclipse? > If so would they be willing to share/put up in the Wiki? > > Thanks > Andrew > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the VTK FAQ at: > http://www.vtk.org/Wiki/VTK_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtkusers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kw_eclipse_style.xml Type: text/xml Size: 17590 bytes Desc: not available URL: From andrew.amaclean at gmail.com Tue Aug 5 21:37:23 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 6 Aug 2014 11:37:23 +1000 Subject: [vtk-developers] [vtkusers] VTK Code Formatting Styles In-Reply-To: References: Message-ID: Thanks David, This is much appreciated. Regards Andrew On Wed, Aug 6, 2014 at 10:59 AM, David E DeMarle wrote: > I use this for eclipse. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > > On Tue, Aug 5, 2014 at 7:32 PM, Andrew Maclean > wrote: > >> Has anyone got: >> 1) A code style for QT Creator for VTK? >> 2) Also one for Eclipse? >> If so would they be willing to share/put up in the Wiki? >> >> Thanks >> Andrew >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.fuger at outlook.com Thu Aug 7 05:03:29 2014 From: markus.fuger at outlook.com (Markus Fuger) Date: Thu, 7 Aug 2014 11:03:29 +0200 Subject: [vtk-developers] Unexpected behaviour of vtkTransformFilter In-Reply-To: References: Message-ID: Hello, I am not entirely sure if I found a bug - but at least it is a behavior I did not expect like that. I do have a vtkUnstructuredGrid object with a 3 component vector as point data. If I apply the vtkTransformFilter with a scaling of - let's say 1000 - in each direction. not only the coordinates get scaled but as well the values within the point data array. Due to the fact, that this data could be a physical value or whatsoever I believe that this is a bug. (I am using vtk6.2 from July 22nd 2014) I could repeat this problem as well in the latest release version of ParaView (4.1). Could perhaps one of the vtk-developers confirm that this is a bug or that this behavior is wanted - because I will then need to change my code. With kind regards, Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Aug 7 07:47:04 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 7 Aug 2014 07:47:04 -0400 Subject: [vtk-developers] Unexpected behaviour of vtkTransformFilter In-Reply-To: References: Message-ID: >From the documentation: // vtkTransformFilter is a filter to transform point coordinates, and // associated point normals and vectors. Other point data is passed // through the filter. On Thu, Aug 7, 2014 at 5:03 AM, Markus Fuger wrote: > Hello, > > I am not entirely sure if I found a bug - but at least it is a behavior I > did not expect like that. > I do have a vtkUnstructuredGrid object with a 3 component vector as point > data. > If I apply the vtkTransformFilter with a scaling of - let's say 1000 - in > each direction. not only the coordinates get scaled but as well the values > within the point data array. Due to the fact, that this data could be a > physical value or whatsoever I believe that this is a bug. (I am using > vtk6.2 from July 22nd 2014) > > I could repeat this problem as well in the latest release version of > ParaView (4.1). > > Could perhaps one of the vtk-developers confirm that this is a bug or that > this behavior is wanted - because I will then need to change my code. > > With kind regards, > Markus > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Fri Aug 8 09:05:19 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Fri, 8 Aug 2014 09:05:19 -0400 Subject: [vtk-developers] any volunteers for vtk qt examples issues? In-Reply-To: References: Message-ID: Turned out to be cmake 2.8.9 had a problem with CMAKE_AUTOMOC ON that Alex fixed in 2.8.10. http://public.kitware.com/Bug/view.php?id=13572 I bumped kargad to cmake 3.0.1 to fix it. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Aug 5, 2014 at 1:47 PM, David E DeMarle wrote: > We turned kargad continuous's examples ON on 4/21, and ever since then it > has had 8 qt related build errors. Any volunteers out there to fix them? > > http://open.cdash.org/viewBuildError.php?buildid=3302083 > > I'm all for updating the qt we use there if that is all it takes. > > 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 rostislav.khlebnikov at kcl.ac.uk Sat Aug 9 14:52:44 2014 From: rostislav.khlebnikov at kcl.ac.uk (Rostislav Khlebnikov) Date: Sat, 9 Aug 2014 19:52:44 +0100 Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator Message-ID: <53E66DFC.201@kcl.ac.uk> Hi guys, just thought that the VTK developers might be interested in the test I made recently. Bascially what I did is subclass the vtkCellLocator to implement the visitor pattern. It allows to filter the octree nodes (e.g. reject the octree nodes that are of no interest early) and for leafs, to visit the cells of the polydata. Then, I subclassed the vtkCutter to use this cell locator instead of straight iteration over cells. Likely for very complex implicit cutting functions this wouldnt be of any benefit. However, for those which can test bboxes as being of interest or not, rejecting whole subtrees, such as vtkPlane, it is very useful. I tested it on a surface with 500k triangles and the cutter performance went from 88ms per cut to 14ms. The code I made is quite ugly due to limited extensibility of vtkCutter, so I had to copy-paste the RequestData method and make my changes instead of, say, overriding IterateCells method which would just provide the cells to cut through. But anyway, I was wondering if you guys are intersted in this kind of functionality? Would you like me to send you the code? All best, Rostislav. From berk.geveci at kitware.com Tue Aug 12 12:44:28 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 12 Aug 2014 12:44:28 -0400 Subject: [vtk-developers] vtkCutter modification to use vtkCellLocator In-Reply-To: <53E66DFC.201@kcl.ac.uk> References: <53E66DFC.201@kcl.ac.uk> Message-ID: Hi Rostislav, This is great. Can you push the code to Gerrit ( http://review.source.kitware.com/)? Best, -berk On Sat, Aug 9, 2014 at 2:52 PM, Rostislav Khlebnikov < rostislav.khlebnikov at kcl.ac.uk> wrote: > Hi guys, > > just thought that the VTK developers might be interested in the test I > made recently. > > Bascially what I did is subclass the vtkCellLocator to implement the > visitor pattern. It allows to filter the octree nodes (e.g. reject the > octree nodes that are of no interest early) and for leafs, to visit the > cells of the polydata. > Then, I subclassed the vtkCutter to use this cell locator instead of > straight iteration over cells. Likely for very complex implicit cutting > functions this wouldnt be of any benefit. However, for those which can test > bboxes as being of interest or not, rejecting whole subtrees, such as > vtkPlane, it is very useful. I tested it on a surface with 500k triangles > and the cutter performance went from 88ms per cut to 14ms. > > The code I made is quite ugly due to limited extensibility of vtkCutter, > so I had to copy-paste the RequestData method and make my changes instead > of, say, overriding IterateCells method which would just provide the cells > to cut through. > > But anyway, I was wondering if you guys are intersted in this kind of > functionality? Would you like me to send you the code? > > All best, > Rostislav. > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodwin.lawlor.lists at gmail.com Wed Aug 13 12:08:14 2014 From: goodwin.lawlor.lists at gmail.com (Goodwin Lawlor) Date: Wed, 13 Aug 2014 17:08:14 +0100 Subject: [vtk-developers] [vtkusers] Problems with ComputeOBB - wrong OBB computed In-Reply-To: References: <1407753513395-5728174.post@n5.nabble.com> <1407848098869-5728187.post@n5.nabble.com> <1407937240013-5728206.post@n5.nabble.com> Message-ID: Would methods like: static int vtkMath::GetMean3 (vtkDataArray *array, double mean[3]) static int vtkMath::GetCovarianceMatrix (vtkDataArray *array, double mean[3], double *covariance) be a better way? Goodwin cf. for VTK devs see http://vtk.markmail.org/search/?q=#query:%20list%3Aorg.vtk.vtkusers+page:1+mid:ppj3wtbusf537spk+state:results On Wed, Aug 13, 2014 at 3:53 PM, Goodwin Lawlor < goodwin.lawlor.lists at gmail.com> wrote: > This wiki page should get you going: > http://www.vtk.org/Wiki/VTK/Git/Develop > > Goodwin > > > On Wed, Aug 13, 2014 at 2:40 PM, Oliver Weinheimer wrote: > >> Hi Goodwin, >> >> yes I also think that this change can improve accuracy also in other >> places >> in VTK. >> In my case, the mean calculation errors built up extremly, so that the >> calculated OBB was unusable. >> No, I'm not familiar with Gerrit, but I will have a look on it. >> Thanks for your reply and help. >> >> Oliver >> >> >> Goodwin Lawlor-2 wrote >> > Hi Oliver, >> > >> > That's a nice method - the mean is gradually accumulated, preserving the >> > accuracy of the floating point value. I'm sure there are other places in >> > VTK that would benefit from this code change... >> > >> > If you're familiar with Gerrit, could you submit this change? I'll have >> a >> > poke around the code base to see if there are other similar mean >> > calculations. >> > >> > Goodwin >> >> >> >> >> >> -- >> View this message in context: >> http://vtk.1045678.n5.nabble.com/Problems-with-ComputeOBB-wrong-OBB-computed-tp5728174p5728206.html >> Sent from the VTK - Users mailing list archive at Nabble.com. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the VTK FAQ at: >> http://www.vtk.org/Wiki/VTK_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtkusers >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinya.onogi at live.jp Thu Aug 14 01:24:05 2014 From: shinya.onogi at live.jp (Onogi Shinya) Date: Thu, 14 Aug 2014 14:24:05 +0900 Subject: [vtk-developers] vtkPistonMapper bug Message-ID: Hi all: vtkPistonMapper calls vtkpiston::CudaRegisterBuffer in every gpu rendering (in vtkPistonMapper.cxx; L181-L186); however, cudaGraphicsUnregisterResource is never called. It results in a gpu resource issue when vtkPistonAlgorithm is updated several times. Quick solution I tested is followings: vtkPistonMapper.cxx 43 void CudaRegisterBuffer(struct cudaGraphicsResource **vboResource, 44 GLuint vboBuffer); + void CudaUnregisterBuffer(struct cudaGraphicsResource **vboResource); 148 if (this->Internal->BufferSize != 0) 149?? { 150??? // Release old buffer +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[0]); +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[1]); +????? vtkpiston::CudaUnregisterResource(this->Internal->vboResources[2]); 151??? vtkgl::DeleteBuffers(3, this->Internal->vboBuffers); vtkPistonMapper.cu void CudaUnregisterResource(struct cudaGraphicsResource *vboResource) { cudaError_t res = cudaGraphicsUnregisterResource(vboResource); if (res != cudaSuccess) { cerr << "Unregister buffer failed ... " << cudaGetErrorString(res) << endl; return; } } But, register/unregister in every rendering wouldn't be needed according to samples of gl interop with cuda. Thnaks, Shinya From dave.demarle at kitware.com Thu Aug 14 10:52:40 2014 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 14 Aug 2014 10:52:40 -0400 Subject: [vtk-developers] vtkPistonMapper bug In-Reply-To: References: Message-ID: Shinya, Would you be please submit this patch to VTK's gerrit review to make it easy to test and integrate your fix? To do that (distilled from http://www.vtk.org/Wiki/VTK/Git/Develop) $ git clone git://vtk.org/VTK.git $ ./Utilities/SetupForDevelopment.sh $ git checkout -b my-topic origin/master $ edit Accelerators/Piston/vtkPistonMapper.cxx $ compile and test locally $ git add file1 file2 file3 $ git commit $ git gerrit-push Choose myself and Robert Maynard as reviewers please in the gerrit web page for the change. Thank you! David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Thu, Aug 14, 2014 at 1:24 AM, Onogi Shinya wrote: > Hi all: > > vtkPistonMapper calls vtkpiston::CudaRegisterBuffer in every gpu rendering > (in vtkPistonMapper.cxx; L181-L186); however, > cudaGraphicsUnregisterResource is never called. It results in a gpu > resource issue when vtkPistonAlgorithm is updated several times. > > Quick solution I tested is followings: > vtkPistonMapper.cxx > 43 void CudaRegisterBuffer(struct cudaGraphicsResource **vboResource, > 44 GLuint vboBuffer); > + void CudaUnregisterBuffer(struct cudaGraphicsResource **vboResource); > > 148 if (this->Internal->BufferSize != 0) > 149 { > 150 // Release old buffer > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[0]); > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[1]); > + vtkpiston::CudaUnregisterResource(this->Internal->vboResources[2]); > 151 vtkgl::DeleteBuffers(3, this->Internal->vboBuffers); > > vtkPistonMapper.cu > void CudaUnregisterResource(struct cudaGraphicsResource *vboResource) > { > cudaError_t res = cudaGraphicsUnregisterResource(vboResource); > if (res != cudaSuccess) > { > cerr << "Unregister buffer failed ... " << cudaGetErrorString(res) << > endl; > return; > } > } > > But, register/unregister in every rendering wouldn't be needed according > to samples of gl interop with cuda. > Thnaks, > Shinya > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Aug 18 13:45:37 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 13:45:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: Hi, As we move forward, it would be great to get a feeling for people's thoughts about integrating some components of C++11 optionally. So if C++11 is available/enabled, there are several features we could enable optionally at compile time. A very simple example is that of the new override keyword, that is used to indicate that a member function is overriding a virtual function. Using this can avoid mistakes where the signature changes and derived classes are missed. It can be defined in a header (empty on old compilers, override with recent compilers). Final is similar, indicating that the virtual function cannot be overridden in derived classes. This would introduce changes to the VTK coding style, where we now use virtual for all virtual functions (first declaration, or subsequent overrides). We could introduce this gradually for new code, even having one or two dashboards compiling this way would help spot simple errors such as an incorrect signature not actually overriding a function, but in fact declaring a new virtual for example. In these cases I would suggest simple naming, so VTK_OVERRIDE and VTK_FINAL would be used where a C++11 only code would simply use the new keywords. Thoughts, objections? There are lots of other features, and I know it will be a while before we can use them all but it would be great to make a start with some of the easier ones that can improve code quality with little overhead. Marcus From ben.boeckel at kitware.com Mon Aug 18 14:21:56 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 18 Aug 2014 14:21:56 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140818182156.GB23226@megas.kitwarein.com> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. What about "= delete" for removing default assignment and copy constructors? --Ben From marcus.hanwell at kitware.com Mon Aug 18 14:29:10 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 14:29:10 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140818182156.GB23226@megas.kitwarein.com> References: <20140818182156.GB23226@megas.kitwarein.com> Message-ID: On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel wrote: > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > Certainly, I think we should start out simple and then build it out. If we have prototypes for a few of the most useful features that can easily be encapsulated in compile time logic that will degrade to C++98 that would be great. Marcus From sean at rogue-research.com Mon Aug 18 16:50:12 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 18 Aug 2014 16:50:12 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140818205012.958234089@mail.rogue-research.com> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >As we move forward, it would be great to get a feeling for people's >thoughts about integrating some components of C++11 optionally. So if >C++11 is available/enabled, there are several features we could enable >optionally at compile time. +1 from me. nullptr is another one that can be made to work even on older compilers with some #define glue. Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if we required C++11 and "#define override /* nothing */" as appropriate. Then when C++11 really is the minimun requirement no big find/replace is required. Just a thought. PS: I already have dashboards building as C++11 and C++14. 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 sean at rogue-research.com Mon Aug 18 17:05:38 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 18 Aug 2014 17:05:38 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140818205012.958234089@mail.rogue-research.com> References: <20140818205012.958234089@mail.rogue-research.com> Message-ID: <20140818210538.1892131851@mail.rogue-research.com> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >nullptr is another one that can be made to work even on older compilers >with some #define glue. > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >we required C++11 and "#define override /* nothing */" as appropriate. >Then when C++11 really is the minimun requirement no big find/replace is >required. Just a thought. I hit send too fast... I also wanted to suggest looking at the clang-modernize tool, which is "a standalone tool used to automatically convert C++ code written against old standards to use features of the newest C++ standard". Specifically, it can be used to automatically add 'override' and convert to 'nullptr': 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 andrew.amaclean at gmail.com Mon Aug 18 18:09:02 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 08:09:02 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: +1! ... actually: ++1 :-) I would support this. To keep VTK relevant we need to be introducing these features. Especially features like nullptr, unique_ptr etc. But I would not be happy at introducing more VTK defines like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of using a modernise tool. Regards Andrew On Tue, Aug 19, 2014 at 7:05 AM, wrote: > > ---------- Forwarded message ---------- > From: "Marcus D. Hanwell" > To: VTK Developers > Cc: > Date: Mon, 18 Aug 2014 13:45:37 -0400 > Subject: [vtk-developers] Introducing (optional) C++11 features in VTK > Hi, > > As we move forward, it would be great to get a feeling for people's > thoughts about integrating some components of C++11 optionally. So if > C++11 is available/enabled, there are several features we could enable > optionally at compile time. > > A very simple example is that of the new override keyword, that is > used to indicate that a member function is overriding a virtual > function. Using this can avoid mistakes where the signature changes > and derived classes are missed. It can be defined in a header (empty > on old compilers, override with recent compilers). Final is similar, > indicating that the virtual function cannot be overridden in derived > classes. > > This would introduce changes to the VTK coding style, where we now use > virtual for all virtual functions (first declaration, or subsequent > overrides). We could introduce this gradually for new code, even > having one or two dashboards compiling this way would help spot simple > errors such as an incorrect signature not actually overriding a > function, but in fact declaring a new virtual for example. > > In these cases I would suggest simple naming, so VTK_OVERRIDE and > VTK_FINAL would be used where a C++11 only code would simply use the > new keywords. > > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. > > Marcus > > > > ---------- Forwarded message ---------- > From: Ben Boeckel > To: "Marcus D. Hanwell" > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:21:56 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > > Thoughts, objections? There are lots of other features, and I know it > > will be a while before we can use them all but it would be great to > > make a start with some of the easier ones that can improve code > > quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > > --Ben > > > > ---------- Forwarded message ---------- > From: "Marcus D. Hanwell" > To: Ben Boeckel > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:29:10 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > wrote: > > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> Thoughts, objections? There are lots of other features, and I know it > >> will be a while before we can use them all but it would be great to > >> make a start with some of the easier ones that can improve code > >> quality with little overhead. > > > > What about "= delete" for removing default assignment and copy > > constructors? > > > Certainly, I think we should start out simple and then build it out. > If we have prototypes for a few of the most useful features that can > easily be encapsulated in compile time logic that will degrade to > C++98 that would be great. > > Marcus > > > > ---------- Forwarded message ---------- > From: "Sean McBride" > To: "Marcus D. Hanwell" , "VTK Developers" < > vtk-developers at vtk.org> > Cc: > Date: Mon, 18 Aug 2014 16:50:12 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > > >As we move forward, it would be great to get a feeling for people's > >thoughts about integrating some components of C++11 optionally. So if > >C++11 is available/enabled, there are several features we could enable > >optionally at compile time. > > +1 from me. > > nullptr is another one that can be made to work even on older compilers > with some #define glue. > > Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if > we required C++11 and "#define override /* nothing */" as appropriate. > Then when C++11 really is the minimun requirement no big find/replace is > required. Just a thought. > > PS: I already have dashboards building as C++11 and C++14. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > > > > ---------- Forwarded message ---------- > From: "Sean McBride" > To: "Marcus D. Hanwell" , "VTK Developers" < > vtk-developers at vtk.org> > Cc: > Date: Mon, 18 Aug 2014 17:05:38 -0400 > Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK > On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > > >nullptr is another one that can be made to work even on older compilers > >with some #define glue. > > > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if > >we required C++11 and "#define override /* nothing */" as appropriate. > >Then when C++11 really is the minimun requirement no big find/replace is > >required. Just a thought. > > I hit send too fast... > > I also wanted to suggest looking at the clang-modernize tool, which is "a > standalone tool used to automatically convert C++ code written against old > standards to use features of the newest C++ standard". > > > > Specifically, it can be used to automatically add 'override' and convert > to 'nullptr': > > > > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Mon Aug 18 18:25:53 2014 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Mon, 18 Aug 2014 22:25:53 +0000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: Message-ID: +1 for me too. However, my vote is actually to introduce things like VTK_OVERRIDE and VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting when libraries try to get cute with changing the behavior of (or trying to emulate) keywords with preprocessor macros. It can be pretty confusing when something goes wrong, and good luck if you have to use two separate projects together that both tried to define preprocessor macros with different implementations. -Ken From: Andrew Maclean > Reply-To: "andrew.amaclean at gmail.com" > Date: Monday, August 18, 2014 4:09 PM To: VTK Developers >, "Marcus D. Hanwell" >, Ben Boeckel >, Sean McBride > Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 features in VTK +1! ... actually: ++1 :-) I would support this. To keep VTK relevant we need to be introducing these features. Especially features like nullptr, unique_ptr etc. But I would not be happy at introducing more VTK defines like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of using a modernise tool. Regards Andrew On Tue, Aug 19, 2014 at 7:05 AM, > wrote: ---------- Forwarded message ---------- From: "Marcus D. Hanwell" > To: VTK Developers > Cc: Date: Mon, 18 Aug 2014 13:45:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Hi, As we move forward, it would be great to get a feeling for people's thoughts about integrating some components of C++11 optionally. So if C++11 is available/enabled, there are several features we could enable optionally at compile time. A very simple example is that of the new override keyword, that is used to indicate that a member function is overriding a virtual function. Using this can avoid mistakes where the signature changes and derived classes are missed. It can be defined in a header (empty on old compilers, override with recent compilers). Final is similar, indicating that the virtual function cannot be overridden in derived classes. This would introduce changes to the VTK coding style, where we now use virtual for all virtual functions (first declaration, or subsequent overrides). We could introduce this gradually for new code, even having one or two dashboards compiling this way would help spot simple errors such as an incorrect signature not actually overriding a function, but in fact declaring a new virtual for example. In these cases I would suggest simple naming, so VTK_OVERRIDE and VTK_FINAL would be used where a C++11 only code would simply use the new keywords. Thoughts, objections? There are lots of other features, and I know it will be a while before we can use them all but it would be great to make a start with some of the easier ones that can improve code quality with little overhead. Marcus ---------- Forwarded message ---------- From: Ben Boeckel > To: "Marcus D. Hanwell" > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:21:56 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > Thoughts, objections? There are lots of other features, and I know it > will be a while before we can use them all but it would be great to > make a start with some of the easier ones that can improve code > quality with little overhead. What about "= delete" for removing default assignment and copy constructors? --Ben ---------- Forwarded message ---------- From: "Marcus D. Hanwell" > To: Ben Boeckel > Cc: VTK Developers > Date: Mon, 18 Aug 2014 14:29:10 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > wrote: > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. > > What about "= delete" for removing default assignment and copy > constructors? > Certainly, I think we should start out simple and then build it out. If we have prototypes for a few of the most useful features that can easily be encapsulated in compile time logic that will degrade to C++98 that would be great. Marcus ---------- Forwarded message ---------- From: "Sean McBride" > To: "Marcus D. Hanwell" >, "VTK Developers" > Cc: Date: Mon, 18 Aug 2014 16:50:12 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >As we move forward, it would be great to get a feeling for people's >thoughts about integrating some components of C++11 optionally. So if >C++11 is available/enabled, there are several features we could enable >optionally at compile time. +1 from me. nullptr is another one that can be made to work even on older compilers with some #define glue. Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if we required C++11 and "#define override /* nothing */" as appropriate. Then when C++11 really is the minimun requirement no big find/replace is required. Just a thought. PS: I already have dashboards building as C++11 and C++14. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada ---------- Forwarded message ---------- From: "Sean McBride" > To: "Marcus D. Hanwell" >, "VTK Developers" > Cc: Date: Mon, 18 Aug 2014 17:05:38 -0400 Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >nullptr is another one that can be made to work even on older compilers >with some #define glue. > >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >we required C++11 and "#define override /* nothing */" as appropriate. >Then when C++11 really is the minimun requirement no big find/replace is >required. Just a thought. I hit send too fast... I also wanted to suggest looking at the clang-modernize tool, which is "a standalone tool used to automatically convert C++ code written against old standards to use features of the newest C++ standard". Specifically, it can be used to automatically add 'override' and convert to 'nullptr': Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Aug 18 18:29:59 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 08:29:59 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK Message-ID: Hi Ken Good point, thanks for that. Andrew On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth wrote: > +1 for me too. > > However, my vote is actually to introduce things like VTK_OVERRIDE and > VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting > when libraries try to get cute with changing the behavior of (or trying to > emulate) keywords with preprocessor macros. It can be pretty confusing when > something goes wrong, and good luck if you have to use two separate > projects together that both tried to define preprocessor macros with > different implementations. > > -Ken > > > From: Andrew Maclean > Reply-To: "andrew.amaclean at gmail.com" > Date: Monday, August 18, 2014 4:09 PM > To: VTK Developers , "Marcus D. Hanwell" < > marcus.hanwell at kitware.com>, Ben Boeckel , Sean > McBride > Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > features in VTK > > +1! ... actually: ++1 :-) > > I would support this. To keep VTK relevant we need to be introducing > these features. Especially features like nullptr, unique_ptr etc. > > But I would not be happy at introducing more VTK defines > like VTK_OVERRIDE and VTK_FINAL - unless absolutely necessary. I much > prefer Sean's idea of using a modernise tool. > > Regards > Andrew > > > On Tue, Aug 19, 2014 at 7:05 AM, wrote: > >> >> ---------- Forwarded message ---------- >> From: "Marcus D. Hanwell" >> To: VTK Developers >> Cc: >> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >> Hi, >> >> As we move forward, it would be great to get a feeling for people's >> thoughts about integrating some components of C++11 optionally. So if >> C++11 is available/enabled, there are several features we could enable >> optionally at compile time. >> >> A very simple example is that of the new override keyword, that is >> used to indicate that a member function is overriding a virtual >> function. Using this can avoid mistakes where the signature changes >> and derived classes are missed. It can be defined in a header (empty >> on old compilers, override with recent compilers). Final is similar, >> indicating that the virtual function cannot be overridden in derived >> classes. >> >> This would introduce changes to the VTK coding style, where we now use >> virtual for all virtual functions (first declaration, or subsequent >> overrides). We could introduce this gradually for new code, even >> having one or two dashboards compiling this way would help spot simple >> errors such as an incorrect signature not actually overriding a >> function, but in fact declaring a new virtual for example. >> >> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> VTK_FINAL would be used where a C++11 only code would simply use the >> new keywords. >> >> Thoughts, objections? There are lots of other features, and I know it >> will be a while before we can use them all but it would be great to >> make a start with some of the easier ones that can improve code >> quality with little overhead. >> >> Marcus >> >> >> >> ---------- Forwarded message ---------- >> From: Ben Boeckel >> To: "Marcus D. Hanwell" >> Cc: VTK Developers >> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> > Thoughts, objections? There are lots of other features, and I know it >> > will be a while before we can use them all but it would be great to >> > make a start with some of the easier ones that can improve code >> > quality with little overhead. >> >> What about "= delete" for removing default assignment and copy >> constructors? >> >> --Ben >> >> >> >> ---------- Forwarded message ---------- >> From: "Marcus D. Hanwell" >> To: Ben Boeckel >> Cc: VTK Developers >> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> wrote: >> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >> Thoughts, objections? There are lots of other features, and I know it >> >> will be a while before we can use them all but it would be great to >> >> make a start with some of the easier ones that can improve code >> >> quality with little overhead. >> > >> > What about "= delete" for removing default assignment and copy >> > constructors? >> > >> Certainly, I think we should start out simple and then build it out. >> If we have prototypes for a few of the most useful features that can >> easily be encapsulated in compile time logic that will degrade to >> C++98 that would be great. >> >> Marcus >> >> >> >> ---------- Forwarded message ---------- >> From: "Sean McBride" >> To: "Marcus D. Hanwell" , "VTK Developers" < >> vtk-developers at vtk.org> >> Cc: >> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >> >As we move forward, it would be great to get a feeling for people's >> >thoughts about integrating some components of C++11 optionally. So if >> >C++11 is available/enabled, there are several features we could enable >> >optionally at compile time. >> >> +1 from me. >> >> nullptr is another one that can be made to work even on older compilers >> with some #define glue. >> >> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >> we required C++11 and "#define override /* nothing */" as appropriate. >> Then when C++11 really is the minimun requirement no big find/replace is >> required. Just a thought. >> >> PS: I already have dashboards building as C++11 and C++14. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Sean McBride" >> To: "Marcus D. Hanwell" , "VTK Developers" < >> vtk-developers at vtk.org> >> Cc: >> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in VTK >> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >> >nullptr is another one that can be made to work even on older compilers >> >with some #define glue. >> > >> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >> >we required C++11 and "#define override /* nothing */" as appropriate. >> >Then when C++11 really is the minimun requirement no big find/replace is >> >required. Just a thought. >> >> I hit send too fast... >> >> I also wanted to suggest looking at the clang-modernize tool, which is "a >> standalone tool used to automatically convert C++ code written against old >> standards to use features of the newest C++ standard". >> >> >> >> Specifically, it can be used to automatically add 'override' and convert >> to 'nullptr': >> >> >> >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >> -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Aug 18 18:43:49 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 18 Aug 2014 16:43:49 -0600 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Yes, I also believe that using "#define override" has the potential to cause problems. Let's say that "override" appears as a variable somewhere in code that someone brought into VTK and tested with a C++11 compiler (this is legal, since "override" is not a keyword). Then someone else tries compiling that code on C++03 where the "#define override" is active. All of a sudden, "override" is replaced by nothing anywhere it is used as a variable (or as any other kind of identifier). On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean wrote: > Hi Ken > > Good point, thanks for that. > > Andrew > > > On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > wrote: >> >> +1 for me too. >> >> However, my vote is actually to introduce things like VTK_OVERRIDE and >> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >> when libraries try to get cute with changing the behavior of (or trying to >> emulate) keywords with preprocessor macros. It can be pretty confusing when >> something goes wrong, and good luck if you have to use two separate projects >> together that both tried to define preprocessor macros with different >> implementations. >> >> -Ken >> >> >> From: Andrew Maclean >> Reply-To: "andrew.amaclean at gmail.com" >> Date: Monday, August 18, 2014 4:09 PM >> To: VTK Developers , "Marcus D. Hanwell" >> , Ben Boeckel , Sean >> McBride >> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >> features in VTK >> >> +1! ... actually: ++1 :-) >> >> I would support this. To keep VTK relevant we need to be introducing these >> features. Especially features like nullptr, unique_ptr etc. >> >> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >> using a modernise tool. >> >> Regards >> Andrew >> >> >> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Marcus D. Hanwell" >>> To: VTK Developers >>> Cc: >>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>> Hi, >>> >>> As we move forward, it would be great to get a feeling for people's >>> thoughts about integrating some components of C++11 optionally. So if >>> C++11 is available/enabled, there are several features we could enable >>> optionally at compile time. >>> >>> A very simple example is that of the new override keyword, that is >>> used to indicate that a member function is overriding a virtual >>> function. Using this can avoid mistakes where the signature changes >>> and derived classes are missed. It can be defined in a header (empty >>> on old compilers, override with recent compilers). Final is similar, >>> indicating that the virtual function cannot be overridden in derived >>> classes. >>> >>> This would introduce changes to the VTK coding style, where we now use >>> virtual for all virtual functions (first declaration, or subsequent >>> overrides). We could introduce this gradually for new code, even >>> having one or two dashboards compiling this way would help spot simple >>> errors such as an incorrect signature not actually overriding a >>> function, but in fact declaring a new virtual for example. >>> >>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>> VTK_FINAL would be used where a C++11 only code would simply use the >>> new keywords. >>> >>> Thoughts, objections? There are lots of other features, and I know it >>> will be a while before we can use them all but it would be great to >>> make a start with some of the easier ones that can improve code >>> quality with little overhead. >>> >>> Marcus >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ben Boeckel >>> To: "Marcus D. Hanwell" >>> Cc: VTK Developers >>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> > Thoughts, objections? There are lots of other features, and I know it >>> > will be a while before we can use them all but it would be great to >>> > make a start with some of the easier ones that can improve code >>> > quality with little overhead. >>> >>> What about "= delete" for removing default assignment and copy >>> constructors? >>> >>> --Ben >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Marcus D. Hanwell" >>> To: Ben Boeckel >>> Cc: VTK Developers >>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>> wrote: >>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >> Thoughts, objections? There are lots of other features, and I know it >>> >> will be a while before we can use them all but it would be great to >>> >> make a start with some of the easier ones that can improve code >>> >> quality with little overhead. >>> > >>> > What about "= delete" for removing default assignment and copy >>> > constructors? >>> > >>> Certainly, I think we should start out simple and then build it out. >>> If we have prototypes for a few of the most useful features that can >>> easily be encapsulated in compile time logic that will degrade to >>> C++98 that would be great. >>> >>> Marcus >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Sean McBride" >>> To: "Marcus D. Hanwell" , "VTK Developers" >>> >>> Cc: >>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>> >>> >As we move forward, it would be great to get a feeling for people's >>> >thoughts about integrating some components of C++11 optionally. So if >>> >C++11 is available/enabled, there are several features we could enable >>> >optionally at compile time. >>> >>> +1 from me. >>> >>> nullptr is another one that can be made to work even on older compilers >>> with some #define glue. >>> >>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>> when C++11 really is the minimun requirement no big find/replace is >>> required. Just a thought. >>> >>> PS: I already have dashboards building as C++11 and C++14. >>> >>> Cheers, >>> >>> -- >>> ____________________________________________________________ >>> Sean McBride, B. Eng sean at rogue-research.com >>> Rogue Research www.rogue-research.com >>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Sean McBride" >>> To: "Marcus D. Hanwell" , "VTK Developers" >>> >>> Cc: >>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>> VTK >>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>> >>> >nullptr is another one that can be made to work even on older compilers >>> >with some #define glue. >>> > >>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>> >we required C++11 and "#define override /* nothing */" as appropriate. >>> >Then when C++11 really is the minimun requirement no big find/replace is >>> >required. Just a thought. >>> >>> I hit send too fast... >>> >>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>> standalone tool used to automatically convert C++ code written against old >>> standards to use features of the newest C++ standard". >>> >>> >>> >>> Specifically, it can be used to automatically add 'override' and convert >>> to 'nullptr': >>> >>> >>> >>> >>> Cheers, From marcus.hanwell at kitware.com Mon Aug 18 19:25:04 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 18 Aug 2014 19:25:04 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: I am with David Gobbi and Ken. It would be a simple search and replace once support for pre-C++11 compilers were dropped and the potential for unintended consequences is too great. Glad to see there is general support, I should have included more on my reasoning, but didn't want to go into too much detail on implementation if there was little support for it. It sounds like there is, nullptr is definitely another piece of low hanging fruit. There is lots more that would be great to use, the language is evolving and it is important that we take advantage of the parts that make sense. Marcus On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi wrote: > Yes, I also believe that using "#define override" has the potential to > cause problems. Let's say that "override" appears as a variable > somewhere in code that someone brought into VTK and tested with a > C++11 compiler (this is legal, since "override" is not a keyword). > Then someone else tries compiling that code on C++03 where the > "#define override" is active. All of a sudden, "override" is replaced > by nothing anywhere it is used as a variable (or as any other kind of > identifier). > > > On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > wrote: >> Hi Ken >> >> Good point, thanks for that. >> >> Andrew >> >> >> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >> wrote: >>> >>> +1 for me too. >>> >>> However, my vote is actually to introduce things like VTK_OVERRIDE and >>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >>> when libraries try to get cute with changing the behavior of (or trying to >>> emulate) keywords with preprocessor macros. It can be pretty confusing when >>> something goes wrong, and good luck if you have to use two separate projects >>> together that both tried to define preprocessor macros with different >>> implementations. >>> >>> -Ken >>> >>> >>> From: Andrew Maclean >>> Reply-To: "andrew.amaclean at gmail.com" >>> Date: Monday, August 18, 2014 4:09 PM >>> To: VTK Developers , "Marcus D. Hanwell" >>> , Ben Boeckel , Sean >>> McBride >>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>> features in VTK >>> >>> +1! ... actually: ++1 :-) >>> >>> I would support this. To keep VTK relevant we need to be introducing these >>> features. Especially features like nullptr, unique_ptr etc. >>> >>> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >>> using a modernise tool. >>> >>> Regards >>> Andrew >>> >>> >>> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Marcus D. Hanwell" >>>> To: VTK Developers >>>> Cc: >>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>>> Hi, >>>> >>>> As we move forward, it would be great to get a feeling for people's >>>> thoughts about integrating some components of C++11 optionally. So if >>>> C++11 is available/enabled, there are several features we could enable >>>> optionally at compile time. >>>> >>>> A very simple example is that of the new override keyword, that is >>>> used to indicate that a member function is overriding a virtual >>>> function. Using this can avoid mistakes where the signature changes >>>> and derived classes are missed. It can be defined in a header (empty >>>> on old compilers, override with recent compilers). Final is similar, >>>> indicating that the virtual function cannot be overridden in derived >>>> classes. >>>> >>>> This would introduce changes to the VTK coding style, where we now use >>>> virtual for all virtual functions (first declaration, or subsequent >>>> overrides). We could introduce this gradually for new code, even >>>> having one or two dashboards compiling this way would help spot simple >>>> errors such as an incorrect signature not actually overriding a >>>> function, but in fact declaring a new virtual for example. >>>> >>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>>> VTK_FINAL would be used where a C++11 only code would simply use the >>>> new keywords. >>>> >>>> Thoughts, objections? There are lots of other features, and I know it >>>> will be a while before we can use them all but it would be great to >>>> make a start with some of the easier ones that can improve code >>>> quality with little overhead. >>>> >>>> Marcus >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Ben Boeckel >>>> To: "Marcus D. Hanwell" >>>> Cc: VTK Developers >>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>> > Thoughts, objections? There are lots of other features, and I know it >>>> > will be a while before we can use them all but it would be great to >>>> > make a start with some of the easier ones that can improve code >>>> > quality with little overhead. >>>> >>>> What about "= delete" for removing default assignment and copy >>>> constructors? >>>> >>>> --Ben >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Marcus D. Hanwell" >>>> To: Ben Boeckel >>>> Cc: VTK Developers >>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>>> wrote: >>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>> >> Thoughts, objections? There are lots of other features, and I know it >>>> >> will be a while before we can use them all but it would be great to >>>> >> make a start with some of the easier ones that can improve code >>>> >> quality with little overhead. >>>> > >>>> > What about "= delete" for removing default assignment and copy >>>> > constructors? >>>> > >>>> Certainly, I think we should start out simple and then build it out. >>>> If we have prototypes for a few of the most useful features that can >>>> easily be encapsulated in compile time logic that will degrade to >>>> C++98 that would be great. >>>> >>>> Marcus >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Sean McBride" >>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>> >>>> Cc: >>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>>> >>>> >As we move forward, it would be great to get a feeling for people's >>>> >thoughts about integrating some components of C++11 optionally. So if >>>> >C++11 is available/enabled, there are several features we could enable >>>> >optionally at compile time. >>>> >>>> +1 from me. >>>> >>>> nullptr is another one that can be made to work even on older compilers >>>> with some #define glue. >>>> >>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>>> when C++11 really is the minimun requirement no big find/replace is >>>> required. Just a thought. >>>> >>>> PS: I already have dashboards building as C++11 and C++14. >>>> >>>> Cheers, >>>> >>>> -- >>>> ____________________________________________________________ >>>> Sean McBride, B. Eng sean at rogue-research.com >>>> Rogue Research www.rogue-research.com >>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>> >>>> >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: "Sean McBride" >>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>> >>>> Cc: >>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>> VTK >>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>>> >>>> >nullptr is another one that can be made to work even on older compilers >>>> >with some #define glue. >>>> > >>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>> >we required C++11 and "#define override /* nothing */" as appropriate. >>>> >Then when C++11 really is the minimun requirement no big find/replace is >>>> >required. Just a thought. >>>> >>>> I hit send too fast... >>>> >>>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>>> standalone tool used to automatically convert C++ code written against old >>>> standards to use features of the newest C++ standard". >>>> >>>> >>>> >>>> Specifically, it can be used to automatically add 'override' and convert >>>> to 'nullptr': >>>> >>>> >>>> >>>> >>>> Cheers, > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From matt.mccormick at kitware.com Mon Aug 18 20:19:37 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 18 Aug 2014 20:19:37 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: VTK_OVERRIDE would be nice, and it would be nice to macros that are similar to ITK. Currently there is ITK_OVERRIDE ITK_NOEXCEPT ITK_NULLPTR http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 Thanks, Matt On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell wrote: > I am with David Gobbi and Ken. It would be a simple search and replace > once support for pre-C++11 compilers were dropped and the potential > for unintended consequences is too great. Glad to see there is general > support, I should have included more on my reasoning, but didn't want > to go into too much detail on implementation if there was little > support for it. > > It sounds like there is, nullptr is definitely another piece of low > hanging fruit. There is lots more that would be great to use, the > language is evolving and it is important that we take advantage of the > parts that make sense. > > Marcus > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi wrote: >> Yes, I also believe that using "#define override" has the potential to >> cause problems. Let's say that "override" appears as a variable >> somewhere in code that someone brought into VTK and tested with a >> C++11 compiler (this is legal, since "override" is not a keyword). >> Then someone else tries compiling that code on C++03 where the >> "#define override" is active. All of a sudden, "override" is replaced >> by nothing anywhere it is used as a variable (or as any other kind of >> identifier). >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> wrote: >>> Hi Ken >>> >>> Good point, thanks for that. >>> >>> Andrew >>> >>> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >>> wrote: >>>> >>>> +1 for me too. >>>> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it disconcerting >>>> when libraries try to get cute with changing the behavior of (or trying to >>>> emulate) keywords with preprocessor macros. It can be pretty confusing when >>>> something goes wrong, and good luck if you have to use two separate projects >>>> together that both tried to define preprocessor macros with different >>>> implementations. >>>> >>>> -Ken >>>> >>>> >>>> From: Andrew Maclean >>>> Reply-To: "andrew.amaclean at gmail.com" >>>> Date: Monday, August 18, 2014 4:09 PM >>>> To: VTK Developers , "Marcus D. Hanwell" >>>> , Ben Boeckel , Sean >>>> McBride >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>>> features in VTK >>>> >>>> +1! ... actually: ++1 :-) >>>> >>>> I would support this. To keep VTK relevant we need to be introducing these >>>> features. Especially features like nullptr, unique_ptr etc. >>>> >>>> But I would not be happy at introducing more VTK defines like VTK_OVERRIDE >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's idea of >>>> using a modernise tool. >>>> >>>> Regards >>>> Andrew >>>> >>>> >>>> On Tue, Aug 19, 2014 at 7:05 AM, wrote: >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Marcus D. Hanwell" >>>>> To: VTK Developers >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in VTK >>>>> Hi, >>>>> >>>>> As we move forward, it would be great to get a feeling for people's >>>>> thoughts about integrating some components of C++11 optionally. So if >>>>> C++11 is available/enabled, there are several features we could enable >>>>> optionally at compile time. >>>>> >>>>> A very simple example is that of the new override keyword, that is >>>>> used to indicate that a member function is overriding a virtual >>>>> function. Using this can avoid mistakes where the signature changes >>>>> and derived classes are missed. It can be defined in a header (empty >>>>> on old compilers, override with recent compilers). Final is similar, >>>>> indicating that the virtual function cannot be overridden in derived >>>>> classes. >>>>> >>>>> This would introduce changes to the VTK coding style, where we now use >>>>> virtual for all virtual functions (first declaration, or subsequent >>>>> overrides). We could introduce this gradually for new code, even >>>>> having one or two dashboards compiling this way would help spot simple >>>>> errors such as an incorrect signature not actually overriding a >>>>> function, but in fact declaring a new virtual for example. >>>>> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >>>>> new keywords. >>>>> >>>>> Thoughts, objections? There are lots of other features, and I know it >>>>> will be a while before we can use them all but it would be great to >>>>> make a start with some of the easier ones that can improve code >>>>> quality with little overhead. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Ben Boeckel >>>>> To: "Marcus D. Hanwell" >>>>> Cc: VTK Developers >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>>> > Thoughts, objections? There are lots of other features, and I know it >>>>> > will be a while before we can use them all but it would be great to >>>>> > make a start with some of the easier ones that can improve code >>>>> > quality with little overhead. >>>>> >>>>> What about "= delete" for removing default assignment and copy >>>>> constructors? >>>>> >>>>> --Ben >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Marcus D. Hanwell" >>>>> To: Ben Boeckel >>>>> Cc: VTK Developers >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>>>> wrote: >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>>>> >> Thoughts, objections? There are lots of other features, and I know it >>>>> >> will be a while before we can use them all but it would be great to >>>>> >> make a start with some of the easier ones that can improve code >>>>> >> quality with little overhead. >>>>> > >>>>> > What about "= delete" for removing default assignment and copy >>>>> > constructors? >>>>> > >>>>> Certainly, I think we should start out simple and then build it out. >>>>> If we have prototypes for a few of the most useful features that can >>>>> easily be encapsulated in compile time logic that will degrade to >>>>> C++98 that would be great. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Sean McBride" >>>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>>> >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>>>> >>>>> >As we move forward, it would be great to get a feeling for people's >>>>> >thoughts about integrating some components of C++11 optionally. So if >>>>> >C++11 is available/enabled, there are several features we could enable >>>>> >optionally at compile time. >>>>> >>>>> +1 from me. >>>>> >>>>> nullptr is another one that can be made to work even on older compilers >>>>> with some #define glue. >>>>> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>>> we required C++11 and "#define override /* nothing */" as appropriate. Then >>>>> when C++11 really is the minimun requirement no big find/replace is >>>>> required. Just a thought. >>>>> >>>>> PS: I already have dashboards building as C++11 and C++14. >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> ____________________________________________________________ >>>>> Sean McBride, B. Eng sean at rogue-research.com >>>>> Rogue Research www.rogue-research.com >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: "Sean McBride" >>>>> To: "Marcus D. Hanwell" , "VTK Developers" >>>>> >>>>> Cc: >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features in >>>>> VTK >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>>>> >>>>> >nullptr is another one that can be made to work even on older compilers >>>>> >with some #define glue. >>>>> > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' as if >>>>> >we required C++11 and "#define override /* nothing */" as appropriate. >>>>> >Then when C++11 really is the minimun requirement no big find/replace is >>>>> >required. Just a thought. >>>>> >>>>> I hit send too fast... >>>>> >>>>> I also wanted to suggest looking at the clang-modernize tool, which is "a >>>>> standalone tool used to automatically convert C++ code written against old >>>>> standards to use features of the newest C++ standard". >>>>> >>>>> >>>>> >>>>> Specifically, it can be used to automatically add 'override' and convert >>>>> to 'nullptr': >>>>> >>>>> >>>>> >>>>> >>>>> Cheers, >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From bill.lorensen at gmail.com Mon Aug 18 21:44:02 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 18 Aug 2014 21:44:02 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: +1 On Aug 18, 2014 8:26 PM, "Matt McCormick" wrote: > VTK_OVERRIDE would be nice, and it would be nice to macros that are > similar to ITK. Currently there is > > ITK_OVERRIDE > ITK_NOEXCEPT > ITK_NULLPTR > > > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > > > Thanks, > Matt > > On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > wrote: > > I am with David Gobbi and Ken. It would be a simple search and replace > > once support for pre-C++11 compilers were dropped and the potential > > for unintended consequences is too great. Glad to see there is general > > support, I should have included more on my reasoning, but didn't want > > to go into too much detail on implementation if there was little > > support for it. > > > > It sounds like there is, nullptr is definitely another piece of low > > hanging fruit. There is lots more that would be great to use, the > > language is evolving and it is important that we take advantage of the > > parts that make sense. > > > > Marcus > > > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > wrote: > >> Yes, I also believe that using "#define override" has the potential to > >> cause problems. Let's say that "override" appears as a variable > >> somewhere in code that someone brought into VTK and tested with a > >> C++11 compiler (this is legal, since "override" is not a keyword). > >> Then someone else tries compiling that code on C++03 where the > >> "#define override" is active. All of a sudden, "override" is replaced > >> by nothing anywhere it is used as a variable (or as any other kind of > >> identifier). > >> > >> > >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> wrote: > >>> Hi Ken > >>> > >>> Good point, thanks for that. > >>> > >>> Andrew > >>> > >>> > >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > >>> wrote: > >>>> > >>>> +1 for me too. > >>>> > >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and > >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > disconcerting > >>>> when libraries try to get cute with changing the behavior of (or > trying to > >>>> emulate) keywords with preprocessor macros. It can be pretty > confusing when > >>>> something goes wrong, and good luck if you have to use two separate > projects > >>>> together that both tried to define preprocessor macros with different > >>>> implementations. > >>>> > >>>> -Ken > >>>> > >>>> > >>>> From: Andrew Maclean > >>>> Reply-To: "andrew.amaclean at gmail.com" > >>>> Date: Monday, August 18, 2014 4:09 PM > >>>> To: VTK Developers , "Marcus D. Hanwell" > >>>> , Ben Boeckel , > Sean > >>>> McBride > >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > >>>> features in VTK > >>>> > >>>> +1! ... actually: ++1 :-) > >>>> > >>>> I would support this. To keep VTK relevant we need to be introducing > these > >>>> features. Especially features like nullptr, unique_ptr etc. > >>>> > >>>> But I would not be happy at introducing more VTK defines like > VTK_OVERRIDE > >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > idea of > >>>> using a modernise tool. > >>>> > >>>> Regards > >>>> Andrew > >>>> > >>>> > >>>> On Tue, Aug 19, 2014 at 7:05 AM, > wrote: > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: VTK Developers > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > VTK > >>>>> Hi, > >>>>> > >>>>> As we move forward, it would be great to get a feeling for people's > >>>>> thoughts about integrating some components of C++11 optionally. So if > >>>>> C++11 is available/enabled, there are several features we could > enable > >>>>> optionally at compile time. > >>>>> > >>>>> A very simple example is that of the new override keyword, that is > >>>>> used to indicate that a member function is overriding a virtual > >>>>> function. Using this can avoid mistakes where the signature changes > >>>>> and derived classes are missed. It can be defined in a header (empty > >>>>> on old compilers, override with recent compilers). Final is similar, > >>>>> indicating that the virtual function cannot be overridden in derived > >>>>> classes. > >>>>> > >>>>> This would introduce changes to the VTK coding style, where we now > use > >>>>> virtual for all virtual functions (first declaration, or subsequent > >>>>> overrides). We could introduce this gradually for new code, even > >>>>> having one or two dashboards compiling this way would help spot > simple > >>>>> errors such as an incorrect signature not actually overriding a > >>>>> function, but in fact declaring a new virtual for example. > >>>>> > >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >>>>> VTK_FINAL would be used where a C++11 only code would simply use the > >>>>> new keywords. > >>>>> > >>>>> Thoughts, objections? There are lots of other features, and I know it > >>>>> will be a while before we can use them all but it would be great to > >>>>> make a start with some of the easier ones that can improve code > >>>>> quality with little overhead. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: Ben Boeckel > >>>>> To: "Marcus D. Hanwell" > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> > Thoughts, objections? There are lots of other features, and I know > it > >>>>> > will be a while before we can use them all but it would be great to > >>>>> > make a start with some of the easier ones that can improve code > >>>>> > quality with little overhead. > >>>>> > >>>>> What about "= delete" for removing default assignment and copy > >>>>> constructors? > >>>>> > >>>>> --Ben > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: Ben Boeckel > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel < > ben.boeckel at kitware.com> > >>>>> wrote: > >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> >> Thoughts, objections? There are lots of other features, and I > know it > >>>>> >> will be a while before we can use them all but it would be great > to > >>>>> >> make a start with some of the easier ones that can improve code > >>>>> >> quality with little overhead. > >>>>> > > >>>>> > What about "= delete" for removing default assignment and copy > >>>>> > constructors? > >>>>> > > >>>>> Certainly, I think we should start out simple and then build it out. > >>>>> If we have prototypes for a few of the most useful features that can > >>>>> easily be encapsulated in compile time logic that will degrade to > >>>>> C++98 that would be great. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >>>>> > >>>>> >As we move forward, it would be great to get a feeling for people's > >>>>> >thoughts about integrating some components of C++11 optionally. So > if > >>>>> >C++11 is available/enabled, there are several features we could > enable > >>>>> >optionally at compile time. > >>>>> > >>>>> +1 from me. > >>>>> > >>>>> nullptr is another one that can be made to work even on older > compilers > >>>>> with some #define glue. > >>>>> > >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> we required C++11 and "#define override /* nothing */" as > appropriate. Then > >>>>> when C++11 really is the minimun requirement no big find/replace is > >>>>> required. Just a thought. > >>>>> > >>>>> PS: I already have dashboards building as C++11 and C++14. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> -- > >>>>> ____________________________________________________________ > >>>>> Sean McBride, B. Eng sean at rogue-research.com > >>>>> Rogue Research www.rogue-research.com > >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >>>>> > >>>>> >nullptr is another one that can be made to work even on older > compilers > >>>>> >with some #define glue. > >>>>> > > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> >we required C++11 and "#define override /* nothing */" as > appropriate. > >>>>> >Then when C++11 really is the minimun requirement no big > find/replace is > >>>>> >required. Just a thought. > >>>>> > >>>>> I hit send too fast... > >>>>> > >>>>> I also wanted to suggest looking at the clang-modernize tool, which > is "a > >>>>> standalone tool used to automatically convert C++ code written > against old > >>>>> standards to use features of the newest C++ standard". > >>>>> > >>>>> > >>>>> > >>>>> Specifically, it can be used to automatically add 'override' and > convert > >>>>> to 'nullptr': > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > 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 > > 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 Mon Aug 18 22:28:59 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 19 Aug 2014 12:28:59 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Brilliant! It looks as if ITK has already done a lot of this! Andrew On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick wrote: > VTK_OVERRIDE would be nice, and it would be nice to macros that are > similar to ITK. Currently there is > > ITK_OVERRIDE > ITK_NOEXCEPT > ITK_NULLPTR > > > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > > > Thanks, > Matt > > On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > wrote: > > I am with David Gobbi and Ken. It would be a simple search and replace > > once support for pre-C++11 compilers were dropped and the potential > > for unintended consequences is too great. Glad to see there is general > > support, I should have included more on my reasoning, but didn't want > > to go into too much detail on implementation if there was little > > support for it. > > > > It sounds like there is, nullptr is definitely another piece of low > > hanging fruit. There is lots more that would be great to use, the > > language is evolving and it is important that we take advantage of the > > parts that make sense. > > > > Marcus > > > > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > wrote: > >> Yes, I also believe that using "#define override" has the potential to > >> cause problems. Let's say that "override" appears as a variable > >> somewhere in code that someone brought into VTK and tested with a > >> C++11 compiler (this is legal, since "override" is not a keyword). > >> Then someone else tries compiling that code on C++03 where the > >> "#define override" is active. All of a sudden, "override" is replaced > >> by nothing anywhere it is used as a variable (or as any other kind of > >> identifier). > >> > >> > >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> wrote: > >>> Hi Ken > >>> > >>> Good point, thanks for that. > >>> > >>> Andrew > >>> > >>> > >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth > >>> wrote: > >>>> > >>>> +1 for me too. > >>>> > >>>> However, my vote is actually to introduce things like VTK_OVERRIDE and > >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > disconcerting > >>>> when libraries try to get cute with changing the behavior of (or > trying to > >>>> emulate) keywords with preprocessor macros. It can be pretty > confusing when > >>>> something goes wrong, and good luck if you have to use two separate > projects > >>>> together that both tried to define preprocessor macros with different > >>>> implementations. > >>>> > >>>> -Ken > >>>> > >>>> > >>>> From: Andrew Maclean > >>>> Reply-To: "andrew.amaclean at gmail.com" > >>>> Date: Monday, August 18, 2014 4:09 PM > >>>> To: VTK Developers , "Marcus D. Hanwell" > >>>> , Ben Boeckel , > Sean > >>>> McBride > >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 > >>>> features in VTK > >>>> > >>>> +1! ... actually: ++1 :-) > >>>> > >>>> I would support this. To keep VTK relevant we need to be introducing > these > >>>> features. Especially features like nullptr, unique_ptr etc. > >>>> > >>>> But I would not be happy at introducing more VTK defines like > VTK_OVERRIDE > >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > idea of > >>>> using a modernise tool. > >>>> > >>>> Regards > >>>> Andrew > >>>> > >>>> > >>>> On Tue, Aug 19, 2014 at 7:05 AM, > wrote: > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: VTK Developers > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > VTK > >>>>> Hi, > >>>>> > >>>>> As we move forward, it would be great to get a feeling for people's > >>>>> thoughts about integrating some components of C++11 optionally. So if > >>>>> C++11 is available/enabled, there are several features we could > enable > >>>>> optionally at compile time. > >>>>> > >>>>> A very simple example is that of the new override keyword, that is > >>>>> used to indicate that a member function is overriding a virtual > >>>>> function. Using this can avoid mistakes where the signature changes > >>>>> and derived classes are missed. It can be defined in a header (empty > >>>>> on old compilers, override with recent compilers). Final is similar, > >>>>> indicating that the virtual function cannot be overridden in derived > >>>>> classes. > >>>>> > >>>>> This would introduce changes to the VTK coding style, where we now > use > >>>>> virtual for all virtual functions (first declaration, or subsequent > >>>>> overrides). We could introduce this gradually for new code, even > >>>>> having one or two dashboards compiling this way would help spot > simple > >>>>> errors such as an incorrect signature not actually overriding a > >>>>> function, but in fact declaring a new virtual for example. > >>>>> > >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >>>>> VTK_FINAL would be used where a C++11 only code would simply use the > >>>>> new keywords. > >>>>> > >>>>> Thoughts, objections? There are lots of other features, and I know it > >>>>> will be a while before we can use them all but it would be great to > >>>>> make a start with some of the easier ones that can improve code > >>>>> quality with little overhead. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: Ben Boeckel > >>>>> To: "Marcus D. Hanwell" > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> > Thoughts, objections? There are lots of other features, and I know > it > >>>>> > will be a while before we can use them all but it would be great to > >>>>> > make a start with some of the easier ones that can improve code > >>>>> > quality with little overhead. > >>>>> > >>>>> What about "= delete" for removing default assignment and copy > >>>>> constructors? > >>>>> > >>>>> --Ben > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Marcus D. Hanwell" > >>>>> To: Ben Boeckel > >>>>> Cc: VTK Developers > >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel < > ben.boeckel at kitware.com> > >>>>> wrote: > >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >>>>> >> Thoughts, objections? There are lots of other features, and I > know it > >>>>> >> will be a while before we can use them all but it would be great > to > >>>>> >> make a start with some of the easier ones that can improve code > >>>>> >> quality with little overhead. > >>>>> > > >>>>> > What about "= delete" for removing default assignment and copy > >>>>> > constructors? > >>>>> > > >>>>> Certainly, I think we should start out simple and then build it out. > >>>>> If we have prototypes for a few of the most useful features that can > >>>>> easily be encapsulated in compile time logic that will degrade to > >>>>> C++98 that would be great. > >>>>> > >>>>> Marcus > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >>>>> > >>>>> >As we move forward, it would be great to get a feeling for people's > >>>>> >thoughts about integrating some components of C++11 optionally. So > if > >>>>> >C++11 is available/enabled, there are several features we could > enable > >>>>> >optionally at compile time. > >>>>> > >>>>> +1 from me. > >>>>> > >>>>> nullptr is another one that can be made to work even on older > compilers > >>>>> with some #define glue. > >>>>> > >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> we required C++11 and "#define override /* nothing */" as > appropriate. Then > >>>>> when C++11 really is the minimun requirement no big find/replace is > >>>>> required. Just a thought. > >>>>> > >>>>> PS: I already have dashboards building as C++11 and C++14. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> -- > >>>>> ____________________________________________________________ > >>>>> Sean McBride, B. Eng sean at rogue-research.com > >>>>> Rogue Research www.rogue-research.com > >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ---------- Forwarded message ---------- > >>>>> From: "Sean McBride" > >>>>> To: "Marcus D. Hanwell" , "VTK > Developers" > >>>>> > >>>>> Cc: > >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features > in > >>>>> VTK > >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >>>>> > >>>>> >nullptr is another one that can be made to work even on older > compilers > >>>>> >with some #define glue. > >>>>> > > >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > as if > >>>>> >we required C++11 and "#define override /* nothing */" as > appropriate. > >>>>> >Then when C++11 really is the minimun requirement no big > find/replace is > >>>>> >required. Just a thought. > >>>>> > >>>>> I hit send too fast... > >>>>> > >>>>> I also wanted to suggest looking at the clang-modernize tool, which > is "a > >>>>> standalone tool used to automatically convert C++ code written > against old > >>>>> standards to use features of the newest C++ standard". > >>>>> > >>>>> > >>>>> > >>>>> Specifically, it can be used to automatically add 'override' and > convert > >>>>> to 'nullptr': > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Tue Aug 19 11:16:35 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Tue, 19 Aug 2014 11:16:35 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: Yes, and there are more extensive examples in the Qt project (for 5+), and Boost where they both used the prefixed macro name approach. I can get some of the basics in pretty quickly as I haven't heard much opposition. Marcus On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean wrote: > Brilliant! It looks as if ITK has already done a lot of this! > > > Andrew > > > > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick > wrote: >> >> VTK_OVERRIDE would be nice, and it would be nice to macros that are >> similar to ITK. Currently there is >> >> ITK_OVERRIDE >> ITK_NOEXCEPT >> ITK_NULLPTR >> >> >> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >> >> >> Thanks, >> Matt >> >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >> wrote: >> > I am with David Gobbi and Ken. It would be a simple search and replace >> > once support for pre-C++11 compilers were dropped and the potential >> > for unintended consequences is too great. Glad to see there is general >> > support, I should have included more on my reasoning, but didn't want >> > to go into too much detail on implementation if there was little >> > support for it. >> > >> > It sounds like there is, nullptr is definitely another piece of low >> > hanging fruit. There is lots more that would be great to use, the >> > language is evolving and it is important that we take advantage of the >> > parts that make sense. >> > >> > Marcus >> > >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >> > wrote: >> >> Yes, I also believe that using "#define override" has the potential to >> >> cause problems. Let's say that "override" appears as a variable >> >> somewhere in code that someone brought into VTK and tested with a >> >> C++11 compiler (this is legal, since "override" is not a keyword). >> >> Then someone else tries compiling that code on C++03 where the >> >> "#define override" is active. All of a sudden, "override" is replaced >> >> by nothing anywhere it is used as a variable (or as any other kind of >> >> identifier). >> >> >> >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> >> wrote: >> >>> Hi Ken >> >>> >> >>> Good point, thanks for that. >> >>> >> >>> Andrew >> >>> >> >>> >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >> >>> wrote: >> >>>> >> >>>> +1 for me too. >> >>>> >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >> >>>> and >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >> >>>> disconcerting >> >>>> when libraries try to get cute with changing the behavior of (or >> >>>> trying to >> >>>> emulate) keywords with preprocessor macros. It can be pretty >> >>>> confusing when >> >>>> something goes wrong, and good luck if you have to use two separate >> >>>> projects >> >>>> together that both tried to define preprocessor macros with different >> >>>> implementations. >> >>>> >> >>>> -Ken >> >>>> >> >>>> >> >>>> From: Andrew Maclean >> >>>> Reply-To: "andrew.amaclean at gmail.com" >> >>>> Date: Monday, August 18, 2014 4:09 PM >> >>>> To: VTK Developers , "Marcus D. Hanwell" >> >>>> , Ben Boeckel , >> >>>> Sean >> >>>> McBride >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >> >>>> features in VTK >> >>>> >> >>>> +1! ... actually: ++1 :-) >> >>>> >> >>>> I would support this. To keep VTK relevant we need to be introducing >> >>>> these >> >>>> features. Especially features like nullptr, unique_ptr etc. >> >>>> >> >>>> But I would not be happy at introducing more VTK defines like >> >>>> VTK_OVERRIDE >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >> >>>> idea of >> >>>> using a modernise tool. >> >>>> >> >>>> Regards >> >>>> Andrew >> >>>> >> >>>> >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >> >>>> wrote: >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Marcus D. Hanwell" >> >>>>> To: VTK Developers >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in >> >>>>> VTK >> >>>>> Hi, >> >>>>> >> >>>>> As we move forward, it would be great to get a feeling for people's >> >>>>> thoughts about integrating some components of C++11 optionally. So >> >>>>> if >> >>>>> C++11 is available/enabled, there are several features we could >> >>>>> enable >> >>>>> optionally at compile time. >> >>>>> >> >>>>> A very simple example is that of the new override keyword, that is >> >>>>> used to indicate that a member function is overriding a virtual >> >>>>> function. Using this can avoid mistakes where the signature changes >> >>>>> and derived classes are missed. It can be defined in a header (empty >> >>>>> on old compilers, override with recent compilers). Final is similar, >> >>>>> indicating that the virtual function cannot be overridden in derived >> >>>>> classes. >> >>>>> >> >>>>> This would introduce changes to the VTK coding style, where we now >> >>>>> use >> >>>>> virtual for all virtual functions (first declaration, or subsequent >> >>>>> overrides). We could introduce this gradually for new code, even >> >>>>> having one or two dashboards compiling this way would help spot >> >>>>> simple >> >>>>> errors such as an incorrect signature not actually overriding a >> >>>>> function, but in fact declaring a new virtual for example. >> >>>>> >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >> >>>>> new keywords. >> >>>>> >> >>>>> Thoughts, objections? There are lots of other features, and I know >> >>>>> it >> >>>>> will be a while before we can use them all but it would be great to >> >>>>> make a start with some of the easier ones that can improve code >> >>>>> quality with little overhead. >> >>>>> >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: Ben Boeckel >> >>>>> To: "Marcus D. Hanwell" >> >>>>> Cc: VTK Developers >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >>>>> > Thoughts, objections? There are lots of other features, and I know >> >>>>> > it >> >>>>> > will be a while before we can use them all but it would be great >> >>>>> > to >> >>>>> > make a start with some of the easier ones that can improve code >> >>>>> > quality with little overhead. >> >>>>> >> >>>>> What about "= delete" for removing default assignment and copy >> >>>>> constructors? >> >>>>> >> >>>>> --Ben >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Marcus D. Hanwell" >> >>>>> To: Ben Boeckel >> >>>>> Cc: VTK Developers >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> >>>>> >> >>>>> wrote: >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >>>>> >> Thoughts, objections? There are lots of other features, and I >> >>>>> >> know it >> >>>>> >> will be a while before we can use them all but it would be great >> >>>>> >> to >> >>>>> >> make a start with some of the easier ones that can improve code >> >>>>> >> quality with little overhead. >> >>>>> > >> >>>>> > What about "= delete" for removing default assignment and copy >> >>>>> > constructors? >> >>>>> > >> >>>>> Certainly, I think we should start out simple and then build it out. >> >>>>> If we have prototypes for a few of the most useful features that can >> >>>>> easily be encapsulated in compile time logic that will degrade to >> >>>>> C++98 that would be great. >> >>>>> >> >>>>> Marcus >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Sean McBride" >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >>>>> Developers" >> >>>>> >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >>>>> >> >>>>> >As we move forward, it would be great to get a feeling for people's >> >>>>> >thoughts about integrating some components of C++11 optionally. So >> >>>>> > if >> >>>>> >C++11 is available/enabled, there are several features we could >> >>>>> > enable >> >>>>> >optionally at compile time. >> >>>>> >> >>>>> +1 from me. >> >>>>> >> >>>>> nullptr is another one that can be made to work even on older >> >>>>> compilers >> >>>>> with some #define glue. >> >>>>> >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >> >>>>> as if >> >>>>> we required C++11 and "#define override /* nothing */" as >> >>>>> appropriate. Then >> >>>>> when C++11 really is the minimun requirement no big find/replace is >> >>>>> required. Just a thought. >> >>>>> >> >>>>> PS: I already have dashboards building as C++11 and C++14. >> >>>>> >> >>>>> Cheers, >> >>>>> >> >>>>> -- >> >>>>> ____________________________________________________________ >> >>>>> Sean McBride, B. Eng sean at rogue-research.com >> >>>>> Rogue Research www.rogue-research.com >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> ---------- Forwarded message ---------- >> >>>>> From: "Sean McBride" >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >>>>> Developers" >> >>>>> >> >>>>> Cc: >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >> >>>>> in >> >>>>> VTK >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >>>>> >> >>>>> >nullptr is another one that can be made to work even on older >> >>>>> > compilers >> >>>>> >with some #define glue. >> >>>>> > >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >> >>>>> > as if >> >>>>> >we required C++11 and "#define override /* nothing */" as >> >>>>> > appropriate. >> >>>>> >Then when C++11 really is the minimun requirement no big >> >>>>> > find/replace is >> >>>>> >required. Just a thought. >> >>>>> >> >>>>> I hit send too fast... >> >>>>> >> >>>>> I also wanted to suggest looking at the clang-modernize tool, which >> >>>>> is "a >> >>>>> standalone tool used to automatically convert C++ code written >> >>>>> against old >> >>>>> standards to use features of the newest C++ standard". >> >>>>> >> >>>>> >> >>>>> >> >>>>> Specifically, it can be used to automatically add 'override' and >> >>>>> convert >> >>>>> to 'nullptr': >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Cheers, >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> 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 >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > > > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ From aashish.chaudhary at kitware.com Tue Aug 19 15:52:52 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 15:52:52 -0400 Subject: [vtk-developers] Broken offscreen example Message-ID: vtkImagingFactory does not exists any more. I am going to update this example unless I hear otherwise. http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/OffScreenRendering - aashish -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue Aug 19 16:06:41 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 16:06:41 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: On this note, actually I might remove it altogether if that's Ok. - Aashish On Tue, Aug 19, 2014 at 3:52 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > vtkImagingFactory does not exists any more. I am going to update this > example unless I hear otherwise. > > http://www.vtk.org/Wiki/VTK/Examples/Cxx/Utilities/OffScreenRendering > > - aashish > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From daviddoria at gmail.com Tue Aug 19 16:18:06 2014 From: daviddoria at gmail.com (David Doria) Date: Tue, 19 Aug 2014 16:18:06 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > On this note, actually I might remove it altogether if that's Ok. > > - Aashish > It seems to me that rendering to a file is an important part of some workflows (scripts that generate a sequence of renderings, etc.). I would vote to not remove it. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Tue Aug 19 16:22:29 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 16:22:29 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Sure but the test name and the description is not right. I am ok with creating a new test with the right name for the purpose you mentioned. Makes sense? - Aashish On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: > On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary < > aashish.chaudhary at kitware.com> wrote: > >> On this note, actually I might remove it altogether if that's Ok. >> >> - Aashish >> > > It seems to me that rendering to a file is an important part of some > workflows (scripts that generate a sequence of renderings, etc.). I would > vote to not remove it. > > David > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 19 16:33:48 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:33:48 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Works for me. On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary wrote: > Sure but the test name and the description is not right. I am ok with > creating a new test with the right name for the purpose you mentioned. > > Makes sense? > > - Aashish > > > On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >> >> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >> wrote: >>> >>> On this note, actually I might remove it altogether if that's Ok. >>> >>> - Aashish >> >> >> It seems to me that rendering to a file is an important part of some >> workflows (scripts that generate a sequence of renderings, etc.). I would >> vote to not remove it. >> >> David > > > > > -- > | 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Tue Aug 19 16:35:04 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:35:04 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: And passes on these nightly dashboards: http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen wrote: > Works for me. > > On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary > wrote: >> Sure but the test name and the description is not right. I am ok with >> creating a new test with the right name for the purpose you mentioned. >> >> Makes sense? >> >> - Aashish >> >> >> On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >>> >>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >>> wrote: >>>> >>>> On this note, actually I might remove it altogether if that's Ok. >>>> >>>> - Aashish >>> >>> >>> It seems to me that rendering to a file is an important part of some >>> workflows (scripts that generate a sequence of renderings, etc.). I would >>> vote to not remove it. >>> >>> David >> >> >> >> >> -- >> | 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 >> >> 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 bill.lorensen at gmail.com Tue Aug 19 16:37:05 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 16:37:05 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Requires vtk 5.10 On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen wrote: > And passes on these nightly dashboards: > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 > > > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen wrote: >> Works for me. >> >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary >> wrote: >>> Sure but the test name and the description is not right. I am ok with >>> creating a new test with the right name for the purpose you mentioned. >>> >>> Makes sense? >>> >>> - Aashish >>> >>> >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria wrote: >>>> >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >>>> wrote: >>>>> >>>>> On this note, actually I might remove it altogether if that's Ok. >>>>> >>>>> - Aashish >>>> >>>> >>>> It seems to me that rendering to a file is an important part of some >>>> workflows (scripts that generate a sequence of renderings, etc.). I would >>>> vote to not remove it. >>>> >>>> David >>> >>> >>> >>> >>> -- >>> | 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 >>> >>> 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 -- Unpaid intern in BillsBasement at noware dot com From aashish.chaudhary at kitware.com Tue Aug 19 17:38:32 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 19 Aug 2014 17:38:32 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: Right. Sorry, I didn't quite say it right. I meant that for version 6 or higher, this example is not relevant. It does have the preprocessors but I am wondering if we need better message or just point to the fact that osmesa is compile time only. If we want to keep it like this, then I can add some text in the description. - Aashish On Tue, Aug 19, 2014 at 4:37 PM, Bill Lorensen wrote: > Requires vtk 5.10 > > > On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen > wrote: > > And passes on these nightly dashboards: > > > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 > > > > > > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen > wrote: > >> Works for me. > >> > >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary > >> wrote: > >>> Sure but the test name and the description is not right. I am ok with > >>> creating a new test with the right name for the purpose you mentioned. > >>> > >>> Makes sense? > >>> > >>> - Aashish > >>> > >>> > >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria > wrote: > >>>> > >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary > >>>> wrote: > >>>>> > >>>>> On this note, actually I might remove it altogether if that's Ok. > >>>>> > >>>>> - Aashish > >>>> > >>>> > >>>> It seems to me that rendering to a file is an important part of some > >>>> workflows (scripts that generate a sequence of renderings, etc.). I > would > >>>> vote to not remove it. > >>>> > >>>> David > >>> > >>> > >>> > >>> > >>> -- > >>> | 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 > >>> > >>> 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 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 19 17:57:19 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 19 Aug 2014 17:57:19 -0400 Subject: [vtk-developers] Broken offscreen example In-Reply-To: References: Message-ID: I agree.We should describe how to use osmesa to accomplish offscreen mesa. On Tue, Aug 19, 2014 at 5:38 PM, Aashish Chaudhary wrote: > Right. Sorry, I didn't quite say it right. I meant that for version 6 or > higher, this example is not relevant. It does have the preprocessors but I > am wondering if we need better message or > just point to the fact that osmesa is compile time only. > > If we want to keep it like this, then I can add some text in the > description. > > - Aashish > > > On Tue, Aug 19, 2014 at 4:37 PM, Bill Lorensen > wrote: >> >> Requires vtk 5.10 >> >> >> On Tue, Aug 19, 2014 at 4:35 PM, Bill Lorensen >> wrote: >> > And passes on these nightly dashboards: >> > >> > http://open.cdash.org/testSummary.php?project=32&name=Utilities-OffScreenRendering&date=2014-08-19 >> > >> > >> > On Tue, Aug 19, 2014 at 4:33 PM, Bill Lorensen >> > wrote: >> >> Works for me. >> >> >> >> On Tue, Aug 19, 2014 at 4:22 PM, Aashish Chaudhary >> >> wrote: >> >>> Sure but the test name and the description is not right. I am ok with >> >>> creating a new test with the right name for the purpose you mentioned. >> >>> >> >>> Makes sense? >> >>> >> >>> - Aashish >> >>> >> >>> >> >>> On Tue, Aug 19, 2014 at 4:18 PM, David Doria >> >>> wrote: >> >>>> >> >>>> On Tue, Aug 19, 2014 at 4:06 PM, Aashish Chaudhary >> >>>> wrote: >> >>>>> >> >>>>> On this note, actually I might remove it altogether if that's Ok. >> >>>>> >> >>>>> - Aashish >> >>>> >> >>>> >> >>>> It seems to me that rendering to a file is an important part of some >> >>>> workflows (scripts that generate a sequence of renderings, etc.). I >> >>>> would >> >>>> vote to not remove it. >> >>>> >> >>>> David >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> | 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 >> >>> >> >>> 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 >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > | Aashish Chaudhary > | Technical Leader > | Kitware Inc. > | http://www.kitware.com/company/team/chaudhary.html -- Unpaid intern in BillsBasement at noware dot com From jchris.fillionr at kitware.com Wed Aug 20 17:24:50 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 20 Aug 2014 17:24:50 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: +1 On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell < marcus.hanwell at kitware.com> wrote: > Yes, and there are more extensive examples in the Qt project (for 5+), > and Boost where they both used the prefixed macro name approach. I can > get some of the basics in pretty quickly as I haven't heard much > opposition. > > Marcus > > On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean > wrote: > > Brilliant! It looks as if ITK has already done a lot of this! > > > > > > Andrew > > > > > > > > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick > > wrote: > >> > >> VTK_OVERRIDE would be nice, and it would be nice to macros that are > >> similar to ITK. Currently there is > >> > >> ITK_OVERRIDE > >> ITK_NOEXCEPT > >> ITK_NULLPTR > >> > >> > >> > http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 > >> > >> > >> Thanks, > >> Matt > >> > >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell > >> wrote: > >> > I am with David Gobbi and Ken. It would be a simple search and replace > >> > once support for pre-C++11 compilers were dropped and the potential > >> > for unintended consequences is too great. Glad to see there is general > >> > support, I should have included more on my reasoning, but didn't want > >> > to go into too much detail on implementation if there was little > >> > support for it. > >> > > >> > It sounds like there is, nullptr is definitely another piece of low > >> > hanging fruit. There is lots more that would be great to use, the > >> > language is evolving and it is important that we take advantage of the > >> > parts that make sense. > >> > > >> > Marcus > >> > > >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi > >> > wrote: > >> >> Yes, I also believe that using "#define override" has the potential > to > >> >> cause problems. Let's say that "override" appears as a variable > >> >> somewhere in code that someone brought into VTK and tested with a > >> >> C++11 compiler (this is legal, since "override" is not a keyword). > >> >> Then someone else tries compiling that code on C++03 where the > >> >> "#define override" is active. All of a sudden, "override" is > replaced > >> >> by nothing anywhere it is used as a variable (or as any other kind of > >> >> identifier). > >> >> > >> >> > >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean > >> >> wrote: > >> >>> Hi Ken > >> >>> > >> >>> Good point, thanks for that. > >> >>> > >> >>> Andrew > >> >>> > >> >>> > >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth < > kmorel at sandia.gov> > >> >>> wrote: > >> >>>> > >> >>>> +1 for me too. > >> >>>> > >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE > >> >>>> and > >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it > >> >>>> disconcerting > >> >>>> when libraries try to get cute with changing the behavior of (or > >> >>>> trying to > >> >>>> emulate) keywords with preprocessor macros. It can be pretty > >> >>>> confusing when > >> >>>> something goes wrong, and good luck if you have to use two separate > >> >>>> projects > >> >>>> together that both tried to define preprocessor macros with > different > >> >>>> implementations. > >> >>>> > >> >>>> -Ken > >> >>>> > >> >>>> > >> >>>> From: Andrew Maclean > >> >>>> Reply-To: "andrew.amaclean at gmail.com" > >> >>>> Date: Monday, August 18, 2014 4:09 PM > >> >>>> To: VTK Developers , "Marcus D. Hanwell" > >> >>>> , Ben Boeckel >, > >> >>>> Sean > >> >>>> McBride > >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) > C++11 > >> >>>> features in VTK > >> >>>> > >> >>>> +1! ... actually: ++1 :-) > >> >>>> > >> >>>> I would support this. To keep VTK relevant we need to be > introducing > >> >>>> these > >> >>>> features. Especially features like nullptr, unique_ptr etc. > >> >>>> > >> >>>> But I would not be happy at introducing more VTK defines like > >> >>>> VTK_OVERRIDE > >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's > >> >>>> idea of > >> >>>> using a modernise tool. > >> >>>> > >> >>>> Regards > >> >>>> Andrew > >> >>>> > >> >>>> > >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, > >> >>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Marcus D. Hanwell" > >> >>>>> To: VTK Developers > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 > >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in > >> >>>>> VTK > >> >>>>> Hi, > >> >>>>> > >> >>>>> As we move forward, it would be great to get a feeling for > people's > >> >>>>> thoughts about integrating some components of C++11 optionally. So > >> >>>>> if > >> >>>>> C++11 is available/enabled, there are several features we could > >> >>>>> enable > >> >>>>> optionally at compile time. > >> >>>>> > >> >>>>> A very simple example is that of the new override keyword, that is > >> >>>>> used to indicate that a member function is overriding a virtual > >> >>>>> function. Using this can avoid mistakes where the signature > changes > >> >>>>> and derived classes are missed. It can be defined in a header > (empty > >> >>>>> on old compilers, override with recent compilers). Final is > similar, > >> >>>>> indicating that the virtual function cannot be overridden in > derived > >> >>>>> classes. > >> >>>>> > >> >>>>> This would introduce changes to the VTK coding style, where we now > >> >>>>> use > >> >>>>> virtual for all virtual functions (first declaration, or > subsequent > >> >>>>> overrides). We could introduce this gradually for new code, even > >> >>>>> having one or two dashboards compiling this way would help spot > >> >>>>> simple > >> >>>>> errors such as an incorrect signature not actually overriding a > >> >>>>> function, but in fact declaring a new virtual for example. > >> >>>>> > >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and > >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use > the > >> >>>>> new keywords. > >> >>>>> > >> >>>>> Thoughts, objections? There are lots of other features, and I know > >> >>>>> it > >> >>>>> will be a while before we can use them all but it would be great > to > >> >>>>> make a start with some of the easier ones that can improve code > >> >>>>> quality with little overhead. > >> >>>>> > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: Ben Boeckel > >> >>>>> To: "Marcus D. Hanwell" > >> >>>>> Cc: VTK Developers > >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> >>>>> > Thoughts, objections? There are lots of other features, and I > know > >> >>>>> > it > >> >>>>> > will be a while before we can use them all but it would be great > >> >>>>> > to > >> >>>>> > make a start with some of the easier ones that can improve code > >> >>>>> > quality with little overhead. > >> >>>>> > >> >>>>> What about "= delete" for removing default assignment and copy > >> >>>>> constructors? > >> >>>>> > >> >>>>> --Ben > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Marcus D. Hanwell" > >> >>>>> To: Ben Boeckel > >> >>>>> Cc: VTK Developers > >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel > >> >>>>> > >> >>>>> wrote: > >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: > >> >>>>> >> Thoughts, objections? There are lots of other features, and I > >> >>>>> >> know it > >> >>>>> >> will be a while before we can use them all but it would be > great > >> >>>>> >> to > >> >>>>> >> make a start with some of the easier ones that can improve code > >> >>>>> >> quality with little overhead. > >> >>>>> > > >> >>>>> > What about "= delete" for removing default assignment and copy > >> >>>>> > constructors? > >> >>>>> > > >> >>>>> Certainly, I think we should start out simple and then build it > out. > >> >>>>> If we have prototypes for a few of the most useful features that > can > >> >>>>> easily be encapsulated in compile time logic that will degrade to > >> >>>>> C++98 that would be great. > >> >>>>> > >> >>>>> Marcus > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Sean McBride" > >> >>>>> To: "Marcus D. Hanwell" , "VTK > >> >>>>> Developers" > >> >>>>> > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: > >> >>>>> > >> >>>>> >As we move forward, it would be great to get a feeling for > people's > >> >>>>> >thoughts about integrating some components of C++11 optionally. > So > >> >>>>> > if > >> >>>>> >C++11 is available/enabled, there are several features we could > >> >>>>> > enable > >> >>>>> >optionally at compile time. > >> >>>>> > >> >>>>> +1 from me. > >> >>>>> > >> >>>>> nullptr is another one that can be made to work even on older > >> >>>>> compilers > >> >>>>> with some #define glue. > >> >>>>> > >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' > >> >>>>> as if > >> >>>>> we required C++11 and "#define override /* nothing */" as > >> >>>>> appropriate. Then > >> >>>>> when C++11 really is the minimun requirement no big find/replace > is > >> >>>>> required. Just a thought. > >> >>>>> > >> >>>>> PS: I already have dashboards building as C++11 and C++14. > >> >>>>> > >> >>>>> Cheers, > >> >>>>> > >> >>>>> -- > >> >>>>> ____________________________________________________________ > >> >>>>> Sean McBride, B. Eng sean at rogue-research.com > >> >>>>> Rogue Research www.rogue-research.com > >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ---------- Forwarded message ---------- > >> >>>>> From: "Sean McBride" > >> >>>>> To: "Marcus D. Hanwell" , "VTK > >> >>>>> Developers" > >> >>>>> > >> >>>>> Cc: > >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 > >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 > features > >> >>>>> in > >> >>>>> VTK > >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: > >> >>>>> > >> >>>>> >nullptr is another one that can be made to work even on older > >> >>>>> > compilers > >> >>>>> >with some #define glue. > >> >>>>> > > >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use > 'override' > >> >>>>> > as if > >> >>>>> >we required C++11 and "#define override /* nothing */" as > >> >>>>> > appropriate. > >> >>>>> >Then when C++11 really is the minimun requirement no big > >> >>>>> > find/replace is > >> >>>>> >required. Just a thought. > >> >>>>> > >> >>>>> I hit send too fast... > >> >>>>> > >> >>>>> I also wanted to suggest looking at the clang-modernize tool, > which > >> >>>>> is "a > >> >>>>> standalone tool used to automatically convert C++ code written > >> >>>>> against old > >> >>>>> standards to use features of the newest C++ standard". > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> Specifically, it can be used to automatically add 'override' and > >> >>>>> convert > >> >>>>> to 'nullptr': > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> Cheers, > >> >> _______________________________________________ > >> >> Powered by www.kitware.com > >> >> > >> >> Visit other Kitware open-source projects at > >> >> http://www.kitware.com/opensource/opensource.html > >> >> > >> >> 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 > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > > > > > > -- > > ___________________________________________ > > Andrew J. P. Maclean > > > > ___________________________________________ > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Aug 20 18:39:34 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 21 Aug 2014 08:39:34 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: (I have already shared this with Marcus) To help the process along I did a cursory search and found these links: C++11 Detection with CMake: http://pageant.ghulbus.eu/?p=664 And down in the notes there is a comment from Rolf Eike Beer: I have pushed a repository for this module online. I have incorporated some of your changes, especially the 3 new tests. git clone git://anongit.kde.org/scratch/dakon/cmake-cxx11 This could make a really good basis for the C++11 implementation. I checked out the repository and it seems to work, read CheckCX11features.cmake it creates lots of variables called HAS_CXX11_* e.g. HAS_CXX11_LAMBDA Regards Andrew On Thu, Aug 21, 2014 at 7:24 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > +1 > > > On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell < > marcus.hanwell at kitware.com> wrote: > >> Yes, and there are more extensive examples in the Qt project (for 5+), >> and Boost where they both used the prefixed macro name approach. I can >> get some of the basics in pretty quickly as I haven't heard much >> opposition. >> >> Marcus >> >> On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean >> wrote: >> > Brilliant! It looks as if ITK has already done a lot of this! >> > >> > >> > Andrew >> > >> > >> > >> > On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick >> > wrote: >> >> >> >> VTK_OVERRIDE would be nice, and it would be nice to macros that are >> >> similar to ITK. Currently there is >> >> >> >> ITK_OVERRIDE >> >> ITK_NOEXCEPT >> >> ITK_NULLPTR >> >> >> >> >> >> >> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >> >> >> >> >> >> Thanks, >> >> Matt >> >> >> >> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >> >> wrote: >> >> > I am with David Gobbi and Ken. It would be a simple search and >> replace >> >> > once support for pre-C++11 compilers were dropped and the potential >> >> > for unintended consequences is too great. Glad to see there is >> general >> >> > support, I should have included more on my reasoning, but didn't want >> >> > to go into too much detail on implementation if there was little >> >> > support for it. >> >> > >> >> > It sounds like there is, nullptr is definitely another piece of low >> >> > hanging fruit. There is lots more that would be great to use, the >> >> > language is evolving and it is important that we take advantage of >> the >> >> > parts that make sense. >> >> > >> >> > Marcus >> >> > >> >> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >> >> > wrote: >> >> >> Yes, I also believe that using "#define override" has the potential >> to >> >> >> cause problems. Let's say that "override" appears as a variable >> >> >> somewhere in code that someone brought into VTK and tested with a >> >> >> C++11 compiler (this is legal, since "override" is not a keyword). >> >> >> Then someone else tries compiling that code on C++03 where the >> >> >> "#define override" is active. All of a sudden, "override" is >> replaced >> >> >> by nothing anywhere it is used as a variable (or as any other kind >> of >> >> >> identifier). >> >> >> >> >> >> >> >> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >> >> >> wrote: >> >> >>> Hi Ken >> >> >>> >> >> >>> Good point, thanks for that. >> >> >>> >> >> >>> Andrew >> >> >>> >> >> >>> >> >> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth < >> kmorel at sandia.gov> >> >> >>> wrote: >> >> >>>> >> >> >>>> +1 for me too. >> >> >>>> >> >> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >> >> >>>> and >> >> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >> >> >>>> disconcerting >> >> >>>> when libraries try to get cute with changing the behavior of (or >> >> >>>> trying to >> >> >>>> emulate) keywords with preprocessor macros. It can be pretty >> >> >>>> confusing when >> >> >>>> something goes wrong, and good luck if you have to use two >> separate >> >> >>>> projects >> >> >>>> together that both tried to define preprocessor macros with >> different >> >> >>>> implementations. >> >> >>>> >> >> >>>> -Ken >> >> >>>> >> >> >>>> >> >> >>>> From: Andrew Maclean >> >> >>>> Reply-To: "andrew.amaclean at gmail.com" >> >> >>>> Date: Monday, August 18, 2014 4:09 PM >> >> >>>> To: VTK Developers , "Marcus D. Hanwell" >> >> >>>> , Ben Boeckel < >> ben.boeckel at kitware.com>, >> >> >>>> Sean >> >> >>>> McBride >> >> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) >> C++11 >> >> >>>> features in VTK >> >> >>>> >> >> >>>> +1! ... actually: ++1 :-) >> >> >>>> >> >> >>>> I would support this. To keep VTK relevant we need to be >> introducing >> >> >>>> these >> >> >>>> features. Especially features like nullptr, unique_ptr etc. >> >> >>>> >> >> >>>> But I would not be happy at introducing more VTK defines like >> >> >>>> VTK_OVERRIDE >> >> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >> >> >>>> idea of >> >> >>>> using a modernise tool. >> >> >>>> >> >> >>>> Regards >> >> >>>> Andrew >> >> >>>> >> >> >>>> >> >> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Marcus D. Hanwell" >> >> >>>>> To: VTK Developers >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >> >> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features >> in >> >> >>>>> VTK >> >> >>>>> Hi, >> >> >>>>> >> >> >>>>> As we move forward, it would be great to get a feeling for >> people's >> >> >>>>> thoughts about integrating some components of C++11 optionally. >> So >> >> >>>>> if >> >> >>>>> C++11 is available/enabled, there are several features we could >> >> >>>>> enable >> >> >>>>> optionally at compile time. >> >> >>>>> >> >> >>>>> A very simple example is that of the new override keyword, that >> is >> >> >>>>> used to indicate that a member function is overriding a virtual >> >> >>>>> function. Using this can avoid mistakes where the signature >> changes >> >> >>>>> and derived classes are missed. It can be defined in a header >> (empty >> >> >>>>> on old compilers, override with recent compilers). Final is >> similar, >> >> >>>>> indicating that the virtual function cannot be overridden in >> derived >> >> >>>>> classes. >> >> >>>>> >> >> >>>>> This would introduce changes to the VTK coding style, where we >> now >> >> >>>>> use >> >> >>>>> virtual for all virtual functions (first declaration, or >> subsequent >> >> >>>>> overrides). We could introduce this gradually for new code, even >> >> >>>>> having one or two dashboards compiling this way would help spot >> >> >>>>> simple >> >> >>>>> errors such as an incorrect signature not actually overriding a >> >> >>>>> function, but in fact declaring a new virtual for example. >> >> >>>>> >> >> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >> >> >>>>> VTK_FINAL would be used where a C++11 only code would simply use >> the >> >> >>>>> new keywords. >> >> >>>>> >> >> >>>>> Thoughts, objections? There are lots of other features, and I >> know >> >> >>>>> it >> >> >>>>> will be a while before we can use them all but it would be great >> to >> >> >>>>> make a start with some of the easier ones that can improve code >> >> >>>>> quality with little overhead. >> >> >>>>> >> >> >>>>> Marcus >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: Ben Boeckel >> >> >>>>> To: "Marcus D. Hanwell" >> >> >>>>> Cc: VTK Developers >> >> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >> >> >>>>> > Thoughts, objections? There are lots of other features, and I >> know >> >> >>>>> > it >> >> >>>>> > will be a while before we can use them all but it would be >> great >> >> >>>>> > to >> >> >>>>> > make a start with some of the easier ones that can improve code >> >> >>>>> > quality with little overhead. >> >> >>>>> >> >> >>>>> What about "= delete" for removing default assignment and copy >> >> >>>>> constructors? >> >> >>>>> >> >> >>>>> --Ben >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Marcus D. Hanwell" >> >> >>>>> To: Ben Boeckel >> >> >>>>> Cc: VTK Developers >> >> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell >> wrote: >> >> >>>>> >> Thoughts, objections? There are lots of other features, and I >> >> >>>>> >> know it >> >> >>>>> >> will be a while before we can use them all but it would be >> great >> >> >>>>> >> to >> >> >>>>> >> make a start with some of the easier ones that can improve >> code >> >> >>>>> >> quality with little overhead. >> >> >>>>> > >> >> >>>>> > What about "= delete" for removing default assignment and copy >> >> >>>>> > constructors? >> >> >>>>> > >> >> >>>>> Certainly, I think we should start out simple and then build it >> out. >> >> >>>>> If we have prototypes for a few of the most useful features that >> can >> >> >>>>> easily be encapsulated in compile time logic that will degrade to >> >> >>>>> C++98 that would be great. >> >> >>>>> >> >> >>>>> Marcus >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Sean McBride" >> >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >> >>>>> Developers" >> >> >>>>> >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >> >> >>>>> >> >> >>>>> >As we move forward, it would be great to get a feeling for >> people's >> >> >>>>> >thoughts about integrating some components of C++11 optionally. >> So >> >> >>>>> > if >> >> >>>>> >C++11 is available/enabled, there are several features we could >> >> >>>>> > enable >> >> >>>>> >optionally at compile time. >> >> >>>>> >> >> >>>>> +1 from me. >> >> >>>>> >> >> >>>>> nullptr is another one that can be made to work even on older >> >> >>>>> compilers >> >> >>>>> with some #define glue. >> >> >>>>> >> >> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use >> 'override' >> >> >>>>> as if >> >> >>>>> we required C++11 and "#define override /* nothing */" as >> >> >>>>> appropriate. Then >> >> >>>>> when C++11 really is the minimun requirement no big find/replace >> is >> >> >>>>> required. Just a thought. >> >> >>>>> >> >> >>>>> PS: I already have dashboards building as C++11 and C++14. >> >> >>>>> >> >> >>>>> Cheers, >> >> >>>>> >> >> >>>>> -- >> >> >>>>> ____________________________________________________________ >> >> >>>>> Sean McBride, B. Eng sean at rogue-research.com >> >> >>>>> Rogue Research www.rogue-research.com >> >> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> ---------- Forwarded message ---------- >> >> >>>>> From: "Sean McBride" >> >> >>>>> To: "Marcus D. Hanwell" , "VTK >> >> >>>>> Developers" >> >> >>>>> >> >> >>>>> Cc: >> >> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >> >> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 >> features >> >> >>>>> in >> >> >>>>> VTK >> >> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >> >> >>>>> >> >> >>>>> >nullptr is another one that can be made to work even on older >> >> >>>>> > compilers >> >> >>>>> >with some #define glue. >> >> >>>>> > >> >> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use >> 'override' >> >> >>>>> > as if >> >> >>>>> >we required C++11 and "#define override /* nothing */" as >> >> >>>>> > appropriate. >> >> >>>>> >Then when C++11 really is the minimun requirement no big >> >> >>>>> > find/replace is >> >> >>>>> >required. Just a thought. >> >> >>>>> >> >> >>>>> I hit send too fast... >> >> >>>>> >> >> >>>>> I also wanted to suggest looking at the clang-modernize tool, >> which >> >> >>>>> is "a >> >> >>>>> standalone tool used to automatically convert C++ code written >> >> >>>>> against old >> >> >>>>> standards to use features of the newest C++ standard". >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> Specifically, it can be used to automatically add 'override' and >> >> >>>>> convert >> >> >>>>> to 'nullptr': >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> Cheers, >> >> >> _______________________________________________ >> >> >> Powered by www.kitware.com >> >> >> >> >> >> Visit other Kitware open-source projects at >> >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> >> >> 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 >> >> > >> >> > Follow this link to subscribe/unsubscribe: >> >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > >> > >> > >> > >> > >> > -- >> > ___________________________________________ >> > Andrew J. P. Maclean >> > >> > ___________________________________________ >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > -- > +1 919 869 8849 > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Aug 21 09:20:54 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Aug 2014 09:20:54 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <53F5F236.7030705@kitware.com> On 08/20/2014 06:39 PM, Andrew Maclean wrote: > To help the process along I did a cursory search and found these links: > > C++11 Detection with CMake: http://pageant.ghulbus.eu/?p=664 > > And down in the notes there is a comment from Rolf Eike Beer: > > I have pushed a repository for this module online. I have incorporated some of your changes, especially the 3 new tests. > > git clone git://anongit.kde.org/scratch/dakon/cmake-cxx11 > > This could make a really good basis for the C++11 implementation. > I checked out the repository and it seems to work, read CheckCX11features.cmake > it creates lots of variables called HAS_CXX11_* e.g. HAS_CXX11_LAMBDA That work was originally proposed for inclusion in CMake, but it has been superseded by new builtin features in post-3.0 development. See the new cmake-compile-features(7) manual: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-compile-features.7.rst;hb=4517d6b7 the target_compile_features command: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/command/target_compile_features.rst;hb=4517d6b7 and the WriteCompilerDetectionHeader module: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/WriteCompilerDetectionHeader.cmake;hb=4517d6b7 Of course these won't be available until CMake 3.1 and still require someone to fill in feature tables for MSVC (currently only GCC and Clang are supported). -Brad From marcus.hanwell at kitware.com Fri Aug 22 11:57:56 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 22 Aug 2014 11:57:56 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: So my first pass at this, keeping the bar relatively low for now, http://review.source.kitware.com/#/t/4550/ I have tested this both as default, and forcing to ANSI C++, on GCC 4.9.1. It would be pretty simple to extend this for Clang (I would rather do it in a follow up commit). This does change the default to enable C++11 if the GCC compiler reports it is capable of this, and I verified the VTK_OVERRIDE fails as expected when overriding something that is not virtual. When looking at this it raised the question (for me at least) of whether we ask for ANSI C++, and the standards (I think we should), or the GNU specific extensions (what we were implicitly doing before by passing nothing unless extra warnings were turned on). The features coming up in CMake look great, but I don't think we need to wait in order to use some of the simpler features. It passes on the Gerrit submissions, so nothing terrible happened on the surface, I think this set is pretty conservative. Let me know if you see major issues in the approach, you can see in a single class (vtkBitArray) how VTK_OVERRIDE and VTK_NULLPTR are used. Marcus On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell wrote: > Yes, and there are more extensive examples in the Qt project (for 5+), > and Boost where they both used the prefixed macro name approach. I can > get some of the basics in pretty quickly as I haven't heard much > opposition. > > Marcus > > On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean > wrote: >> Brilliant! It looks as if ITK has already done a lot of this! >> >> >> Andrew >> >> >> >> On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick >> wrote: >>> >>> VTK_OVERRIDE would be nice, and it would be nice to macros that are >>> similar to ITK. Currently there is >>> >>> ITK_OVERRIDE >>> ITK_NOEXCEPT >>> ITK_NULLPTR >>> >>> >>> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121 >>> >>> >>> Thanks, >>> Matt >>> >>> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell >>> wrote: >>> > I am with David Gobbi and Ken. It would be a simple search and replace >>> > once support for pre-C++11 compilers were dropped and the potential >>> > for unintended consequences is too great. Glad to see there is general >>> > support, I should have included more on my reasoning, but didn't want >>> > to go into too much detail on implementation if there was little >>> > support for it. >>> > >>> > It sounds like there is, nullptr is definitely another piece of low >>> > hanging fruit. There is lots more that would be great to use, the >>> > language is evolving and it is important that we take advantage of the >>> > parts that make sense. >>> > >>> > Marcus >>> > >>> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi >>> > wrote: >>> >> Yes, I also believe that using "#define override" has the potential to >>> >> cause problems. Let's say that "override" appears as a variable >>> >> somewhere in code that someone brought into VTK and tested with a >>> >> C++11 compiler (this is legal, since "override" is not a keyword). >>> >> Then someone else tries compiling that code on C++03 where the >>> >> "#define override" is active. All of a sudden, "override" is replaced >>> >> by nothing anywhere it is used as a variable (or as any other kind of >>> >> identifier). >>> >> >>> >> >>> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean >>> >> wrote: >>> >>> Hi Ken >>> >>> >>> >>> Good point, thanks for that. >>> >>> >>> >>> Andrew >>> >>> >>> >>> >>> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth >>> >>> wrote: >>> >>>> >>> >>>> +1 for me too. >>> >>>> >>> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE >>> >>>> and >>> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it >>> >>>> disconcerting >>> >>>> when libraries try to get cute with changing the behavior of (or >>> >>>> trying to >>> >>>> emulate) keywords with preprocessor macros. It can be pretty >>> >>>> confusing when >>> >>>> something goes wrong, and good luck if you have to use two separate >>> >>>> projects >>> >>>> together that both tried to define preprocessor macros with different >>> >>>> implementations. >>> >>>> >>> >>>> -Ken >>> >>>> >>> >>>> >>> >>>> From: Andrew Maclean >>> >>>> Reply-To: "andrew.amaclean at gmail.com" >>> >>>> Date: Monday, August 18, 2014 4:09 PM >>> >>>> To: VTK Developers , "Marcus D. Hanwell" >>> >>>> , Ben Boeckel , >>> >>>> Sean >>> >>>> McBride >>> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11 >>> >>>> features in VTK >>> >>>> >>> >>>> +1! ... actually: ++1 :-) >>> >>>> >>> >>>> I would support this. To keep VTK relevant we need to be introducing >>> >>>> these >>> >>>> features. Especially features like nullptr, unique_ptr etc. >>> >>>> >>> >>>> But I would not be happy at introducing more VTK defines like >>> >>>> VTK_OVERRIDE >>> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's >>> >>>> idea of >>> >>>> using a modernise tool. >>> >>>> >>> >>>> Regards >>> >>>> Andrew >>> >>>> >>> >>>> >>> >>>> On Tue, Aug 19, 2014 at 7:05 AM, >>> >>>> wrote: >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Marcus D. Hanwell" >>> >>>>> To: VTK Developers >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400 >>> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in >>> >>>>> VTK >>> >>>>> Hi, >>> >>>>> >>> >>>>> As we move forward, it would be great to get a feeling for people's >>> >>>>> thoughts about integrating some components of C++11 optionally. So >>> >>>>> if >>> >>>>> C++11 is available/enabled, there are several features we could >>> >>>>> enable >>> >>>>> optionally at compile time. >>> >>>>> >>> >>>>> A very simple example is that of the new override keyword, that is >>> >>>>> used to indicate that a member function is overriding a virtual >>> >>>>> function. Using this can avoid mistakes where the signature changes >>> >>>>> and derived classes are missed. It can be defined in a header (empty >>> >>>>> on old compilers, override with recent compilers). Final is similar, >>> >>>>> indicating that the virtual function cannot be overridden in derived >>> >>>>> classes. >>> >>>>> >>> >>>>> This would introduce changes to the VTK coding style, where we now >>> >>>>> use >>> >>>>> virtual for all virtual functions (first declaration, or subsequent >>> >>>>> overrides). We could introduce this gradually for new code, even >>> >>>>> having one or two dashboards compiling this way would help spot >>> >>>>> simple >>> >>>>> errors such as an incorrect signature not actually overriding a >>> >>>>> function, but in fact declaring a new virtual for example. >>> >>>>> >>> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and >>> >>>>> VTK_FINAL would be used where a C++11 only code would simply use the >>> >>>>> new keywords. >>> >>>>> >>> >>>>> Thoughts, objections? There are lots of other features, and I know >>> >>>>> it >>> >>>>> will be a while before we can use them all but it would be great to >>> >>>>> make a start with some of the easier ones that can improve code >>> >>>>> quality with little overhead. >>> >>>>> >>> >>>>> Marcus >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: Ben Boeckel >>> >>>>> To: "Marcus D. Hanwell" >>> >>>>> Cc: VTK Developers >>> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >>>>> > Thoughts, objections? There are lots of other features, and I know >>> >>>>> > it >>> >>>>> > will be a while before we can use them all but it would be great >>> >>>>> > to >>> >>>>> > make a start with some of the easier ones that can improve code >>> >>>>> > quality with little overhead. >>> >>>>> >>> >>>>> What about "= delete" for removing default assignment and copy >>> >>>>> constructors? >>> >>>>> >>> >>>>> --Ben >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Marcus D. Hanwell" >>> >>>>> To: Ben Boeckel >>> >>>>> Cc: VTK Developers >>> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel >>> >>>>> >>> >>>>> wrote: >>> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote: >>> >>>>> >> Thoughts, objections? There are lots of other features, and I >>> >>>>> >> know it >>> >>>>> >> will be a while before we can use them all but it would be great >>> >>>>> >> to >>> >>>>> >> make a start with some of the easier ones that can improve code >>> >>>>> >> quality with little overhead. >>> >>>>> > >>> >>>>> > What about "= delete" for removing default assignment and copy >>> >>>>> > constructors? >>> >>>>> > >>> >>>>> Certainly, I think we should start out simple and then build it out. >>> >>>>> If we have prototypes for a few of the most useful features that can >>> >>>>> easily be encapsulated in compile time logic that will degrade to >>> >>>>> C++98 that would be great. >>> >>>>> >>> >>>>> Marcus >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Sean McBride" >>> >>>>> To: "Marcus D. Hanwell" , "VTK >>> >>>>> Developers" >>> >>>>> >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said: >>> >>>>> >>> >>>>> >As we move forward, it would be great to get a feeling for people's >>> >>>>> >thoughts about integrating some components of C++11 optionally. So >>> >>>>> > if >>> >>>>> >C++11 is available/enabled, there are several features we could >>> >>>>> > enable >>> >>>>> >optionally at compile time. >>> >>>>> >>> >>>>> +1 from me. >>> >>>>> >>> >>>>> nullptr is another one that can be made to work even on older >>> >>>>> compilers >>> >>>>> with some #define glue. >>> >>>>> >>> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >>> >>>>> as if >>> >>>>> we required C++11 and "#define override /* nothing */" as >>> >>>>> appropriate. Then >>> >>>>> when C++11 really is the minimun requirement no big find/replace is >>> >>>>> required. Just a thought. >>> >>>>> >>> >>>>> PS: I already have dashboards building as C++11 and C++14. >>> >>>>> >>> >>>>> Cheers, >>> >>>>> >>> >>>>> -- >>> >>>>> ____________________________________________________________ >>> >>>>> Sean McBride, B. Eng sean at rogue-research.com >>> >>>>> Rogue Research www.rogue-research.com >>> >>>>> Mac Software Developer Montr?al, Qu?bec, Canada >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> ---------- Forwarded message ---------- >>> >>>>> From: "Sean McBride" >>> >>>>> To: "Marcus D. Hanwell" , "VTK >>> >>>>> Developers" >>> >>>>> >>> >>>>> Cc: >>> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400 >>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features >>> >>>>> in >>> >>>>> VTK >>> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said: >>> >>>>> >>> >>>>> >nullptr is another one that can be made to work even on older >>> >>>>> > compilers >>> >>>>> >with some #define glue. >>> >>>>> > >>> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override' >>> >>>>> > as if >>> >>>>> >we required C++11 and "#define override /* nothing */" as >>> >>>>> > appropriate. >>> >>>>> >Then when C++11 really is the minimun requirement no big >>> >>>>> > find/replace is >>> >>>>> >required. Just a thought. >>> >>>>> >>> >>>>> I hit send too fast... >>> >>>>> >>> >>>>> I also wanted to suggest looking at the clang-modernize tool, which >>> >>>>> is "a >>> >>>>> standalone tool used to automatically convert C++ code written >>> >>>>> against old >>> >>>>> standards to use features of the newest C++ standard". >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Specifically, it can be used to automatically add 'override' and >>> >>>>> convert >>> >>>>> to 'nullptr': >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Cheers, >>> >> _______________________________________________ >>> >> Powered by www.kitware.com >>> >> >>> >> Visit other Kitware open-source projects at >>> >> http://www.kitware.com/opensource/opensource.html >>> >> >>> >> 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 >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ From sean at rogue-research.com Fri Aug 22 13:15:39 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 13:15:39 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: Message-ID: <20140822171539.406274357@mail.rogue-research.com> Marcus, First, thanks for working on this! I realize you are just testing things out, but some comments nonetheless: On Fri, 22 Aug 2014 11:57:56 -0400, Marcus D. Hanwell said: >So my first pass at this, keeping the bar relatively low for now, > >http://review.source.kitware.com/#/t/4550/ > >I have tested this both as default, and forcing to ANSI C++, on GCC >4.9.1. It would be pretty simple to extend this for Clang (I would >rather do it in a follow up commit). I think the term "ANSI C++" is horribly ambiguous, and shouldn't be used (ex: VTK_FORCE_ANSI_CXX). Honestly, I'm not even sure what you mean by it. Do you mean C++98? The string "ANSI" doesn't even appear on the wikipedia C++ page: :) Better to use these names IMNSHO: >This does change the default to >enable C++11 if the GCC compiler reports it is capable of this I would argue against forcing any particular dialect. It seems to me that that should be an explicit choice made by the user at compile time. Specially since VTK is a library. If my app is built as C++98 and VTK 6.2 suddenly decides to build itself as C++11 then I could easily get freaky link errors because of changes to mangling, etc. >verified the VTK_OVERRIDE fails as expected when overriding something >that is not virtual. When looking at this it raised the question (for >me at least) of whether we ask for ANSI C++, and the standards (I >think we should), or the GNU specific extensions (what we were >implicitly doing before by passing nothing unless extra warnings were >turned on). As VTK is cross platform, best to use as few gcc extensions as possible, none ideally. clang has a warning that warns when gcc extensions are used, as I recall there are a few in the VTK codebase, like using C99 VLAs in C++ files. I'll do a build and see how many warnings pop... >The features coming up in CMake look great, but I don't think we need >to wait in order to use some of the simpler features. Agreed. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From marcus.hanwell at kitware.com Fri Aug 22 13:25:54 2014 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Fri, 22 Aug 2014 13:25:54 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140822171539.406274357@mail.rogue-research.com> References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: On Fri, Aug 22, 2014 at 1:15 PM, Sean McBride wrote: > Marcus, > > First, thanks for working on this! > > I realize you are just testing things out, but some comments nonetheless: > > > On Fri, 22 Aug 2014 11:57:56 -0400, Marcus D. Hanwell said: > >>So my first pass at this, keeping the bar relatively low for now, >> >>http://review.source.kitware.com/#/t/4550/ >> >>I have tested this both as default, and forcing to ANSI C++, on GCC >>4.9.1. It would be pretty simple to extend this for Clang (I would >>rather do it in a follow up commit). > > I think the term "ANSI C++" is horribly ambiguous, and shouldn't be used (ex: VTK_FORCE_ANSI_CXX). Honestly, I'm not even sure what you mean by it. Do you mean C++98? > > The string "ANSI" doesn't even appear on the wikipedia C++ page: :) > Wikipedia isn't the only source of information, http://www.cplusplus.com/info/faq/ talks about it, and http://gcc.gnu.org/onlinedocs/gcc/Standards.html discusses the -ansi flag, versus the -std=blah. I am not particularly tied to it, but it is fairly widely used. > > Better to use these names IMNSHO: > > >>This does change the default to >>enable C++11 if the GCC compiler reports it is capable of this > > I would argue against forcing any particular dialect. It seems to me that that should be an explicit choice made by the user at compile time. Specially since VTK is a library. If my app is built as C++98 and VTK 6.2 suddenly decides to build itself as C++11 then I could easily get freaky link errors because of changes to mangling, etc. This is where I was less certain, although I am not aware of changes in mangling for stuff we care about - do you have examples here, or just being cautious? As far as I know the MSVC compilers enable all new C++ features by default, whereas GCC/Clang need it to be enabled. > >>verified the VTK_OVERRIDE fails as expected when overriding something >>that is not virtual. When looking at this it raised the question (for >>me at least) of whether we ask for ANSI C++, and the standards (I >>think we should), or the GNU specific extensions (what we were >>implicitly doing before by passing nothing unless extra warnings were >>turned on). > > As VTK is cross platform, best to use as few gcc extensions as possible, none ideally. > > clang has a warning that warns when gcc extensions are used, as I recall there are a few in the VTK codebase, like using C99 VLAs in C++ files. I'll do a build and see how many warnings pop... I doubt we have many, as we normally make people fix these in review and they cause failures on Windows for example. I guess we can go with explicitly enabling, but at some point we may want to change this to the other way around. Otherwise you end up with a bunch of features most developers/users never see/enable as they are not aware of all the flags. Maybe we want a meta flag for VTK - enable new stuff, as GCC visibility is off by default, extra compiler warnings, possibly now new C++ features, and it is quite a list to enable one-by-one. We can take some time to mull it over, but I personally wouldn't mind the enable all new features flag grouping. Marcus From sean at rogue-research.com Fri Aug 22 13:58:43 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 13:58:43 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: <20140822175843.864531183@mail.rogue-research.com> On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: >Wikipedia isn't the only source of information, >http://www.cplusplus.com/info/faq/ talks about it, and >http://gcc.gnu.org/onlinedocs/gcc/Standards.html discusses the -ansi >flag, versus the -std=blah. I am not particularly tied to it, but it >is fairly widely used. It can of course be widely used and ambiguous at the same time. :) It's similarly ambiguous to refer to "ISO C", as there have been several over the years. 4th google result for "ANSI C++": I think saying "C++98" (or "ISO C++98") is unarguably clearer than saying "ANSI C++". >This is where I was less certain, although I am not aware of changes >in mangling for stuff we care about - do you have examples here, or >just being cautious? The latter. "The C++98 language is ABI-compatible with the C++11 language, but several places in the library break compatibility. This makes it dangerous to link C++98 objects with C++11 objects." 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 sean at rogue-research.com Fri Aug 22 17:21:42 2014 From: sean at rogue-research.com (Sean McBride) Date: Fri, 22 Aug 2014 17:21:42 -0400 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: References: <20140822171539.406274357@mail.rogue-research.com> Message-ID: <20140822212142.260638657@mail.rogue-research.com> On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: >> clang has a warning that warns when gcc extensions are used, as I >recall there are a few in the VTK codebase, like using C99 VLAs in C++ >files. I'll do a build and see how many warnings pop... > >I doubt we have many, as we normally make people fix these in review >and they cause failures on Windows for example. So I built with clang and "-std=c++11 -stdlib=libc++ -pedantic -Wno-extra-semi" and there were only a few warnings: a) 15 of the form: VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2568:5: warning: variable length arrays are a C99 feature [-Wvla-extension] ALLOC_LOCAL_ARRAY( derivatives, REAL2, nv-1 ); ^ VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2201:49: note: expanded from macro 'ALLOC_LOCAL_ARRAY' #define ALLOC_LOCAL_ARRAY(name,type,n) type name[(n)] ^ This works in Windows as there is a malloc fallback case. b) 3 of the form: VTK/Rendering/Label/vtkLabelHierarchy.cxx:887:10: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion] if ( &(this->Node->value()) ) ~~ ~^~~~~~~~~~~~~~~~~~~~ VTK/Utilities/octree/octree_node.h:48:13: note: 'value' returns a reference reference value() { return this->_M_data; } ^ 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 andrew.amaclean at gmail.com Sat Aug 23 02:35:02 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sat, 23 Aug 2014 16:35:02 +1000 Subject: [vtk-developers] Introducing (optional) C++11 features in VTK In-Reply-To: <20140822212142.260638657@mail.rogue-research.com> References: <20140822171539.406274357@mail.rogue-research.com> <20140822212142.260638657@mail.rogue-research.com> Message-ID: Just did a bit of digging around in the Microsoft documentation and it seems VS2012 and VS2013 support final, override and nullptr. There is a lot of info and tables here: http://msdn.microsoft.com/en-us/library/hh567368.aspx final: VS2012/2013 overrride: VS2012/2013 nullptr VS2010/2013 So you can probably allow their use for these compilers in VTK. Probably somewhere in vtkCompilerExtras.cmake and vtkWin32Header.h. Actually there is CMAKE_CXX_COMPILER_ID, CMAKE_CXX_COMPILER_VERSION available but I am not sure it was accessible in cmake 2.8.8 (the minimum for VTK). For VS2013 I get Compiler ID/Version: MSVC 18.0.30723.0 (however I am using CMake 3.1). CMAKE_CXX_COMPILER_ID returns at least one of "GNU", "MSVC", "Clang". Andrew Andrew Andrew On Sat, Aug 23, 2014 at 7:21 AM, Sean McBride wrote: > On Fri, 22 Aug 2014 13:25:54 -0400, Marcus D. Hanwell said: > > >> clang has a warning that warns when gcc extensions are used, as I > >recall there are a few in the VTK codebase, like using C99 VLAs in C++ > >files. I'll do a build and see how many warnings pop... > > > >I doubt we have many, as we normally make people fix these in review > >and they cause failures on Windows for example. > > So I built with clang and "-std=c++11 -stdlib=libc++ -pedantic > -Wno-extra-semi" and there were only a few warnings: > > a) 15 of the form: > > VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2568:5: warning: > variable length arrays are a C99 feature [-Wvla-extension] > ALLOC_LOCAL_ARRAY( derivatives, REAL2, nv-1 ); > ^ > VTK/Filters/General/vtkYoungsMaterialInterface.cxx:2201:49: note: expanded > from macro 'ALLOC_LOCAL_ARRAY' > #define ALLOC_LOCAL_ARRAY(name,type,n) type name[(n)] > ^ > > This works in Windows as there is a malloc fallback case. > > > > b) 3 of the form: > > VTK/Rendering/Label/vtkLabelHierarchy.cxx:887:10: warning: reference > cannot be bound to dereferenced null pointer in well-defined C++ code; > pointer may be assumed to always convert to true > [-Wundefined-bool-conversion] > if ( &(this->Node->value()) ) > ~~ ~^~~~~~~~~~~~~~~~~~~~ > VTK/Utilities/octree/octree_node.h:48:13: note: 'value' returns a reference > reference value() { return this->_M_data; } > ^ > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.finet at kitware.com Sat Aug 23 16:25:02 2014 From: julien.finet at kitware.com (Julien Finet) Date: Sat, 23 Aug 2014 16:25:02 -0400 Subject: [vtk-developers] When calling vtkWidgetRepresentation::BuildRepresentation() ? Message-ID: Hi, Short story: When should BuildRepresentation() be called ? Long story: I was facing a rendering issue with vtkOrientedPolygonalHandleRepresentation3D. The handle was not being rendered until I moved the camera to a special orientation. The issue was that the widget representation actor was being culled by the renderer which prevented any rendering from happening. And only a rendering (e.g. RenderOpaqueGeometry()) could update the actor position via BuildRepresentation(). Browsing through the code, it seems that it is being called at different places: a) when a display property is being called (e.g. vtkSplineRepresentation::SetClosed) b) when bounds are being called (e.g. vtkLineRepresentation::GetBounds()) c) after widgetInteraction is called (e.g. vtkBorderRepresentation::WidgetInteraction() d) when rendering is being called (e.g. vtkProp3DButtonRepresentation:: RenderOpaqueGeometry()) e) By the widget (e.g. vtkSliderWidget::AnimateSlider(), vtkAngleWidget::MoveAction()). It seems to be at the same time than c) Did I miss something ? Here are critics against each solution: a) seems a bit against the idea that BuildRepresentation() compresses all the Modified() events and creates/refresh the representation when all the changes are done. b) Do we know for sure GetBounds() is being called by the renderer before displaying any vtkProp ? c) What if the representation has no interaction ? (processing of events being OFF) d) As explained in my long story, it is too late to refresh the representation. (Rendering may never be called if the representation is not built') e) Same as d) Do you disagree with my critics ? Did I forget anything obvious ? It seems that b) (in GetBounds()) is the only valid location. Would you agree ? Thanks for those who read through my long email :-) Julien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 19:58:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 19:58:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: Hi folks, It is time for us to look at our options to replace our current Gerrit instance (review.source.kitware.com). Here is some background information: review.source.kitware.com runs a fork of the Gerrit code base from quite a while ago. The main feature of the fork is the support for topics (branches). The original Gerrit only supports reviewing of individual commits (changes) and has no concept of branches. The lack of support for branches is an issue for us from both automated testing and review point of view. So we extended Gerrit to support branches. Alas, our changes have not been accepted upstream and we are not interested in putting more effort in maintaining the fork as Gerrit code advances. So we can not make use of new Gerrit features and more importantly security fixes. So it is time to move on. I would like to start this process with a discussion of workflows (rather than tools). Let's first figure out one or more ideal (and reasonable) workflows. Then we can discuss tools to achieve these workflows and make a decision. Here I'll list some requirements that I thought are important in no particular order: - Maintain an open and "democratic" review process, a la Gerrit voting support. - The workflow needs to be distributed and not require a single (or a few) maintainer to integrate code. A la our Gerrit's review and merge support. - Workflow needs to scale with the community size. - Support for cdash @ home style testing of code under review before integration. - Support for arbitrary server side checks beyond cdash @ home before integration. - Support for "audit trail". There needs to be way of getting to the original discussion and reviews that led to the acceptance of a particular branch. I will follow up with a few initial workflow suggestions. Please send your workflow suggestions or requirements. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:04:34 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:04:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: Github / Bitbucket / Gitlab style workflow: This workflow is based on pull requests. A process through which anyone with an account can request a particular branch be merged to the original repository. There is usually support for discussion of individual pull requests and possibly support for approving of requests by community members (Bitbucket for example). This workflow supports branches with arbitrary numbers of commits. Diffs for the whole branch and individual commits are provided. The discussion usually happens around the diff of the whole branch. This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool. On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci wrote: > Hi folks, > > It is time for us to look at our options to replace our current Gerrit > instance (review.source.kitware.com). > > Here is some background information: review.source.kitware.com runs a > fork of the Gerrit code base from quite a while ago. The main feature of > the fork is the support for topics (branches). The original Gerrit only > supports reviewing of individual commits (changes) and has no concept of > branches. The lack of support for branches is an issue for us from both > automated testing and review point of view. So we extended Gerrit to > support branches. Alas, our changes have not been accepted upstream and we > are not interested in putting more effort in maintaining the fork as Gerrit > code advances. So we can not make use of new Gerrit features and more > importantly security fixes. So it is time to move on. > > I would like to start this process with a discussion of workflows (rather > than tools). Let's first figure out one or more ideal (and reasonable) > workflows. Then we can discuss tools to achieve these workflows and make a > decision. > > Here I'll list some requirements that I thought are important in no > particular order: > > - Maintain an open and "democratic" review process, a la Gerrit voting > support. > > - The workflow needs to be distributed and not require a single (or a few) > maintainer to integrate code. A la our Gerrit's review and merge support. > > - Workflow needs to scale with the community size. > > - Support for cdash @ home style testing of code under review before > integration. > > - Support for arbitrary server side checks beyond cdash @ home before > integration. > > - Support for "audit trail". There needs to be way of getting to the > original discussion and reviews that led to the acceptance of a particular > branch. > > I will follow up with a few initial workflow suggestions. Please send your > workflow suggestions or requirements. > > Best, > -berk > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:07:30 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:07:30 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: Vanilla Gerrit workflow: This workflow is based on reviewing individual commits. Merging also happens at individual commit level. Discussions and voting happen per commit. This workflow is almost entirely driven by a Web interface. Discussions happen almost entirely in the Web tool. On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci wrote: > Github / Bitbucket / Gitlab style workflow: > > This workflow is based on pull requests. A process through which anyone > with an account can request a particular branch be merged to the original > repository. There is usually support for discussion of individual pull > requests and possibly support for approving of requests by community > members (Bitbucket for example). This workflow supports branches with > arbitrary numbers of commits. Diffs for the whole branch and individual > commits are provided. The discussion usually happens around the diff of the > whole branch. > > This workflow is almost entirely driven by a Web interface. Discussions > happen almost entirely in the Web tool. > > > On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci > wrote: > >> Hi folks, >> >> It is time for us to look at our options to replace our current Gerrit >> instance (review.source.kitware.com). >> >> Here is some background information: review.source.kitware.com runs a >> fork of the Gerrit code base from quite a while ago. The main feature of >> the fork is the support for topics (branches). The original Gerrit only >> supports reviewing of individual commits (changes) and has no concept of >> branches. The lack of support for branches is an issue for us from both >> automated testing and review point of view. So we extended Gerrit to >> support branches. Alas, our changes have not been accepted upstream and we >> are not interested in putting more effort in maintaining the fork as Gerrit >> code advances. So we can not make use of new Gerrit features and more >> importantly security fixes. So it is time to move on. >> >> I would like to start this process with a discussion of workflows (rather >> than tools). Let's first figure out one or more ideal (and reasonable) >> workflows. Then we can discuss tools to achieve these workflows and make a >> decision. >> >> Here I'll list some requirements that I thought are important in no >> particular order: >> >> - Maintain an open and "democratic" review process, a la Gerrit voting >> support. >> >> - The workflow needs to be distributed and not require a single (or a >> few) maintainer to integrate code. A la our Gerrit's review and merge >> support. >> >> - Workflow needs to scale with the community size. >> >> - Support for cdash @ home style testing of code under review before >> integration. >> >> - Support for arbitrary server side checks beyond cdash @ home before >> integration. >> >> - Support for "audit trail". There needs to be way of getting to the >> original discussion and reviews that led to the acceptance of a particular >> branch. >> >> I will follow up with a few initial workflow suggestions. Please send >> your workflow suggestions or requirements. >> >> Best, >> -berk >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Sat Aug 23 20:13:27 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sat, 23 Aug 2014 20:13:27 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: E-mail workflow (similar to Linux kernel): In this workflow, discussions on commits/branches happen on the mailing list. This workflow could be augmented by Web tools such as Github and Gist. However, merge requests and discussions happen on the mailing list. On Sat, Aug 23, 2014 at 8:07 PM, Berk Geveci wrote: > Vanilla Gerrit workflow: > > This workflow is based on reviewing individual commits. Merging also > happens at individual commit level. Discussions and voting happen per > commit. > > This workflow is almost entirely driven by a Web interface. Discussions > happen almost entirely in the Web tool. > > > On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci > wrote: > >> Github / Bitbucket / Gitlab style workflow: >> >> This workflow is based on pull requests. A process through which anyone >> with an account can request a particular branch be merged to the original >> repository. There is usually support for discussion of individual pull >> requests and possibly support for approving of requests by community >> members (Bitbucket for example). This workflow supports branches with >> arbitrary numbers of commits. Diffs for the whole branch and individual >> commits are provided. The discussion usually happens around the diff of the >> whole branch. >> >> This workflow is almost entirely driven by a Web interface. Discussions >> happen almost entirely in the Web tool. >> >> >> On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci >> wrote: >> >>> Hi folks, >>> >>> It is time for us to look at our options to replace our current Gerrit >>> instance (review.source.kitware.com). >>> >>> Here is some background information: review.source.kitware.com runs a >>> fork of the Gerrit code base from quite a while ago. The main feature of >>> the fork is the support for topics (branches). The original Gerrit only >>> supports reviewing of individual commits (changes) and has no concept of >>> branches. The lack of support for branches is an issue for us from both >>> automated testing and review point of view. So we extended Gerrit to >>> support branches. Alas, our changes have not been accepted upstream and we >>> are not interested in putting more effort in maintaining the fork as Gerrit >>> code advances. So we can not make use of new Gerrit features and more >>> importantly security fixes. So it is time to move on. >>> >>> I would like to start this process with a discussion of workflows >>> (rather than tools). Let's first figure out one or more ideal (and >>> reasonable) workflows. Then we can discuss tools to achieve these workflows >>> and make a decision. >>> >>> Here I'll list some requirements that I thought are important in no >>> particular order: >>> >>> - Maintain an open and "democratic" review process, a la Gerrit voting >>> support. >>> >>> - The workflow needs to be distributed and not require a single (or a >>> few) maintainer to integrate code. A la our Gerrit's review and merge >>> support. >>> >>> - Workflow needs to scale with the community size. >>> >>> - Support for cdash @ home style testing of code under review before >>> integration. >>> >>> - Support for arbitrary server side checks beyond cdash @ home before >>> integration. >>> >>> - Support for "audit trail". There needs to be way of getting to the >>> original discussion and reviews that led to the acceptance of a particular >>> branch. >>> >>> I will follow up with a few initial workflow suggestions. Please send >>> your workflow suggestions or requirements. >>> >>> Best, >>> -berk >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Sat Aug 23 21:04:32 2014 From: david.thompson at kitware.com (David Thompson) Date: Sat, 23 Aug 2014 21:04:32 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Hi Berk, > It is time for us to look at our options to replace our current Gerrit instance (review.source.kitware.com). ... > Here I'll list some requirements that I thought are important in no particular order: > - Maintain an open and "democratic" review process, a la Gerrit voting support. +1 > - The workflow needs to be distributed and not require a single (or a few) maintainer to integrate code. A la our Gerrit's review and merge support. Distributed is great. But it also helps to have stakeholders for particular pieces of code, especially for core functionality, whose buy-off (or at least notification) is required. > - Support for cdash @ home style testing of code under review before integration. +1 > - Support for arbitrary server side checks beyond cdash @ home before integration. As long as arbitrary does not become whimsical. For instance, whitespace rules make it very un-fun to keep third-party libraries up to date in VTK; when a library like netcdf or exodus does not have strict rules about trailing whitespace, merging in a new release from upstream is tedious. > - Support for "audit trail". There needs to be way of getting to the original discussion and reviews that led to the acceptance of a particular branch. +1 Also, it should be easy to find the audit trail starting with a git hash. > I will follow up with a few initial workflow suggestions. Please send your workflow suggestions or requirements. Suggestions: - It takes a long time for tests to run because VTK is large. Often, changes to non-core functionality run a lot of unnecessary, unrelated tests. It would be nice to have submitters and/or reviewers force a few tests by name and let the review system choose other tests to run using some static analysis to find tests that have a chance of executing the updated code. Since CDash tracks average test time, it would be easy to have a time budget for choosing tests. - It would be nice to have tighter integration with the release process and issue tracking so that reports of features added and bugs fixed could be generated. I think what we do of that is mostly by hand now, isn't it? Suggested Requirements:-) - Review system comments should be Markdown or rST or something easily presented as HTML which can include links -- at least to the VTK wiki and bug tracker, if nothing else. It would be really nice if pull requests could effectively become parts of a wiki page or blog so that we could curate user-guide-style documentation instead of just doxygen reference docs. Not that every topic would have to become part of a user's guide, but it should be easy to pull topic info into a user's guide. - An anti-requirement: Less e-mail spam when (1) a topic includes multiple commits and/or (2) automated testing completes. For instance, I can think of one topic I'm a reviewer on that has 40-something commits. There are 16 changesets and reviewers get 1 per commit per changeset-the-commit-is-modified. 2?, David From david.gobbi at gmail.com Sat Aug 23 22:18:11 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 23 Aug 2014 20:18:11 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I'm all for sticking with gerrit. I'll be sad to lose the topic review interface, but topics in vanilla gerrit really aren't that bad. We'll still be able to push topics and we'll be able to see all the changes that make up a topic. I believe that what we lose is 1) the ability to do a topic-level review and 2) the ability to browse by topic. The only thing that annoys me with gerrit is that when you click "review", it hides all of the previous review comments until you're done. Hopefully the new gerrit has fixed this. The things I'd like to see in a code review system are: - Tight integration with the bugtracker. - Some kind of incentive for reviewers, even if it's just gold stars or a "top reviewer" list. Or we could be draconian and enforce a review/submit ratio, just like the old BBS's enforced upload/download ratios. - David From david.thompson at kitware.com Sat Aug 23 22:25:02 2014 From: david.thompson at kitware.com (David Thompson) Date: Sat, 23 Aug 2014 22:25:02 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> > ... The only thing that annoys me with gerrit is that when you click > "review", it hides all of the previous review comments until you're > done. ... This reminds me of another Gerrit annoyance: it is very difficult to get Gerrit to show you the difference between changeset revisions. I forget whether it happens at the topic or the changeset level, but Gerrit has a bug that prevents this kind of diff. If someone uploads a new revision of a topic it is important to be able to see the diffs to the previous revision, not just the branch point. David From david.gobbi at gmail.com Sat Aug 23 23:17:25 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 23 Aug 2014 21:17:25 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> Message-ID: On Sat, Aug 23, 2014 at 8:25 PM, David Thompson wrote: > This reminds me of another Gerrit annoyance: it is very difficult > to get Gerrit to show you the difference between changeset > revisions. I forget whether it happens at the topic or the changeset > level, but Gerrit has a bug that prevents this kind of diff. If someone > uploads a new revision of a topic it is important to be able to see > the diffs to the previous revision, not just the branch point. This problem occurs at the changeset level whenever the topic is rebased. Submitters should avoid gratuitous rebasing. - David From berk.geveci at kitware.com Sun Aug 24 08:37:43 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Sun, 24 Aug 2014 08:37:43 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Hi David, >From what I can tell, you can't even get the order of changesets in a topic in vanilla Gerrit. You can search by a topic but that seems to be it for topic support. Also, I don't think that there is any way of merging an entire topic. That's changeset based too. So based on what I see, I disagree with " topics in vanilla gerrit really aren't that bad" :-) If we were to use Gerrit, I think that we would have to require that branches are squashed to 1 commit except unusual circumstances. So a clarification to what I meant by vanilla Gerrit workflow: for the most part, the workflow would require branches of single or at most a few commits. Longer running branches with 10s of commits would be a major pain to manage in Gerrit and would probably require special handling. -berk On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi wrote: > I'm all for sticking with gerrit. I'll be sad to lose the topic > review interface, but topics in vanilla gerrit really aren't that bad. > We'll still be able to push topics and we'll be able to see all the > changes that make up a topic. I believe that what we lose is 1) the > ability to do a topic-level review and 2) the ability to browse by > topic. > > The only thing that annoys me with gerrit is that when you click > "review", it hides all of the previous review comments until you're > done. Hopefully the new gerrit has fixed this. > > The things I'd like to see in a code review system are: > > - Tight integration with the bugtracker. > > - Some kind of incentive for reviewers, even if it's just gold stars > or a "top reviewer" list. > > Or we could be draconian and enforce a review/submit ratio, just like > the old BBS's enforced upload/download ratios. > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Sun Aug 24 12:52:34 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 24 Aug 2014 12:52:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I prefer Vanilla Gerrit. I always liked single commits. And, ITK is using pretty much the vanilla workflow. On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci wrote: > Hi David, > > From what I can tell, you can't even get the order of changesets in a topic > in vanilla Gerrit. You can search by a topic but that seems to be it for > topic support. Also, I don't think that there is any way of merging an > entire topic. That's changeset based too. > > So based on what I see, I disagree with " topics in vanilla gerrit really > aren't that bad" :-) If we were to use Gerrit, I think that we would have to > require that branches are squashed to 1 commit except unusual circumstances. > > So a clarification to what I meant by vanilla Gerrit workflow: for the most > part, the workflow would require branches of single or at most a few > commits. Longer running branches with 10s of commits would be a major pain > to manage in Gerrit and would probably require special handling. > > -berk > > > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi wrote: >> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >> review interface, but topics in vanilla gerrit really aren't that bad. >> We'll still be able to push topics and we'll be able to see all the >> changes that make up a topic. I believe that what we lose is 1) the >> ability to do a topic-level review and 2) the ability to browse by >> topic. >> >> The only thing that annoys me with gerrit is that when you click >> "review", it hides all of the previous review comments until you're >> done. Hopefully the new gerrit has fixed this. >> >> The things I'd like to see in a code review system are: >> >> - Tight integration with the bugtracker. >> >> - Some kind of incentive for reviewers, even if it's just gold stars >> or a "top reviewer" list. >> >> Or we could be draconian and enforce a review/submit ratio, just like >> the old BBS's enforced upload/download ratios. >> >> - David > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From andrew.amaclean at gmail.com Sun Aug 24 20:05:35 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 25 Aug 2014 10:05:35 +1000 Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: Hi Berk, After giving this a bit of thought I would prefer the Github/Bitbucket/Gitlab style of workflow. To me the key requirements for a review/testing/integration system are: A) The system itself: - A simple to use (and pretty) web interface that is relatively intuitive. Casual users shouldn't be daunted by the interface. We need their input to enhance the code base. - The enterprise (Kitware) should be able set up and host on its own internal sites. - Integration of bug/issue reporting would be nice. Currently the Mantis system is completely separate. - Branch level access control is essential e.g the VTK Master 6.x and the older VTK 5.10 branch. - Users: Granularity is essential e.g anyone can submit modifications but only a select few have rights to perform merges with the master or designated branches like VTK 6.1 etc. This is just the sandbox principle ... making sure that the code won't break the main release/development branches. - Users: Users should be validated - personally I don't see anything wrong with users providing their real name. - The system itself should be well maintained and responsive to requests for changes. In other words the review/testing/integration code base should be using its own system. B) Reviewing and merging code: - Code definitely needs to be verified by something like cdash at home. - Merges to the master (or a particular branch) only be done after review. - Merges be done by small number of designated personnel that have these rights. - Audit trails are essential. C) Conclusion So I guess I lean towards the Github/Bitbucket/Gitlab style of workflow with possibly Gitlab being able to fulfill all of these requirements (but I not an expert - I have only used Github and Bitbucket, and have just done some reading up on Gitlab). Another key reason to go this way is that a lot of our users in the medical, science and research fields are familiar with the web interface/usage paradigm and they are busy people. Having a web interface that is easy to use allows them to check in when they can and make modifying/adding code and bug submissions etc. easy for them. With respect to the other two workflows: The vanilla gerrit: possibly too complex for the casual user and is missing a nice web interface and bug reporting system. The email workflow: whilst it works with the Linux kernel, we need the user to interact in their own time and place, hence the web interface is much better in this respect. I think you would also need a dedicated mailing list for this, which would reduce the usability for a lot of casual users. Regards Andrew > ---------- Forwarded message ---------- > From: Berk Geveci > To: VTK Developers > Cc: > Date: Sat, 23 Aug 2014 20:13:27 -0400 > Subject: Re: [vtk-developers] VTK code review / testing / integration > workflow > E-mail workflow (similar to Linux kernel): > > In this workflow, discussions on commits/branches happen on the mailing > list. This workflow could be augmented by Web tools such as Github and > Gist. However, merge requests and discussions happen on the mailing list. > > > On Sat, Aug 23, 2014 at 8:07 PM, Berk Geveci > wrote: > >> Vanilla Gerrit workflow: >> >> This workflow is based on reviewing individual commits. Merging also >> happens at individual commit level. Discussions and voting happen per >> commit. >> >> This workflow is almost entirely driven by a Web interface. Discussions >> happen almost entirely in the Web tool. >> >> >> On Sat, Aug 23, 2014 at 8:04 PM, Berk Geveci >> wrote: >> >>> Github / Bitbucket / Gitlab style workflow: >>> >>> This workflow is based on pull requests. A process through which anyone >>> with an account can request a particular branch be merged to the original >>> repository. There is usually support for discussion of individual pull >>> requests and possibly support for approving of requests by community >>> members (Bitbucket for example). This workflow supports branches with >>> arbitrary numbers of commits. Diffs for the whole branch and individual >>> commits are provided. The discussion usually happens around the diff of the >>> whole branch. >>> >>> This workflow is almost entirely driven by a Web interface. Discussions >>> happen almost entirely in the Web tool. >>> >>> >>> On Sat, Aug 23, 2014 at 7:58 PM, Berk Geveci >>> wrote: >>> >>>> Hi folks, >>>> >>>> It is time for us to look at our options to replace our current Gerrit >>>> instance (review.source.kitware.com). >>>> >>>> Here is some background information: review.source.kitware.com runs a >>>> fork of the Gerrit code base from quite a while ago. The main feature of >>>> the fork is the support for topics (branches). The original Gerrit only >>>> supports reviewing of individual commits (changes) and has no concept of >>>> branches. The lack of support for branches is an issue for us from both >>>> automated testing and review point of view. So we extended Gerrit to >>>> support branches. Alas, our changes have not been accepted upstream and we >>>> are not interested in putting more effort in maintaining the fork as Gerrit >>>> code advances. So we can not make use of new Gerrit features and more >>>> importantly security fixes. So it is time to move on. >>>> >>>> I would like to start this process with a discussion of workflows >>>> (rather than tools). Let's first figure out one or more ideal (and >>>> reasonable) workflows. Then we can discuss tools to achieve these workflows >>>> and make a decision. >>>> >>>> Here I'll list some requirements that I thought are important in no >>>> particular order: >>>> >>>> - Maintain an open and "democratic" review process, a la Gerrit voting >>>> support. >>>> >>>> - The workflow needs to be distributed and not require a single (or a >>>> few) maintainer to integrate code. A la our Gerrit's review and merge >>>> support. >>>> >>>> - Workflow needs to scale with the community size. >>>> >>>> - Support for cdash @ home style testing of code under review before >>>> integration. >>>> >>>> - Support for arbitrary server side checks beyond cdash @ home before >>>> integration. >>>> >>>> - Support for "audit trail". There needs to be way of getting to the >>>> original discussion and reviews that led to the acceptance of a particular >>>> branch. >>>> >>>> I will follow up with a few initial workflow suggestions. Please send >>>> your workflow suggestions or requirements. >>>> >>>> Best, >>>> -berk >>>> >>>> >>>> >>>> >>>> >>> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Aug 25 08:38:25 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 08:38:25 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> Message-ID: <20140825123825.GA512@megas.kitwarein.com> On Sat, Aug 23, 2014 at 22:25:02 -0400, David Thompson wrote: > This reminds me of another Gerrit annoyance: it is very difficult to > get Gerrit to show you the difference between changeset revisions. I > forget whether it happens at the topic or the changeset level, but > Gerrit has a bug that prevents this kind of diff. If someone uploads a > new revision of a topic it is important to be able to see the diffs to > the previous revision, not just the branch point. When viewing a diff, you can click "Patch Sets" at the top to get a bunch of radio buttons to choose the old/new revision to view. --Ben From ben.boeckel at kitware.com Mon Aug 25 08:51:55 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 08:51:55 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: Message-ID: <20140825125155.GB512@megas.kitwarein.com> On Sat, Aug 23, 2014 at 19:58:53 -0400, Berk Geveci wrote: > I will follow up with a few initial workflow suggestions. Please send your > workflow suggestions or requirements. What about the ability to handle "in-progress" branch reviews more gracefully? Currently, there are a couple of things in Gerrit which greatly hinder this: - Gerrit hurks something awful when a commit shows up in two branches (unified-bindings had a branch split off from it and some commits abandoned and/or merged?which broke unified-bindings' review and is presently unviewable in Gerrit at all[1] and cannot be closed or abandoned); - Gerrit is awful at branch dependencies (mainly due to the lack of the concept and attempts being thwarted by the above issue); - Comments are per patch set and not carried over if the commented-on code didn't change which makes fixing half the comments on a review a pain. --Ben [1]http://review.source.kitware.com/#/t/3199/ From dlrdave at aol.com Mon Aug 25 10:24:44 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 10:24:44 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825123825.GA512@megas.kitwarein.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> <20140825123825.GA512@megas.kitwarein.com> Message-ID: <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> >> This reminds me of another Gerrit annoyance: it is very difficult to >> get Gerrit to show you the difference between changeset revisions. > When viewing a diff, you can click "Patch Sets" at the top to get a > bunch of radio buttons to choose the old/new revision to view. That's exactly the view that gets messed up when somebody does a rebase in between patch sets. It's only useful all the time if everybody agrees to avoid rebasing changesets. D From dlrdave at aol.com Mon Aug 25 10:29:27 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 10:29:27 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825125155.GB512@megas.kitwarein.com> References: <20140825125155.GB512@megas.kitwarein.com> Message-ID: <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> > - Gerrit hurks something awful when a commit shows up in two branches > - Gerrit is awful at branch dependencies (mainly due to the lack of > the concept and attempts being thwarted by the above issue); Perhaps, just perhaps, avoiding branch dependencies in the first place is the proper solution to such a problem, rather than requiring your review tool to handle it. Branch dependencies are also hard to handle from a mental/human perspective -- it's not just the tools -- better to have independent branches. Or, to wait for the first branch to make it all the way back to master before starting the second branch. I know, I know. git was supposed to eliminate the need for patience and perseverence, right? ;-) > - Comments are per patch set and not carried over if the commented-on > code didn't change which makes fixing half the comments on a review > a pain. That is a pain -- but is it handled any better in one of the other suggested workflows? D From ben.boeckel at kitware.com Mon Aug 25 11:02:17 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 11:02:17 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> References: <20140825125155.GB512@megas.kitwarein.com> <8D18E881BECB449-1E58-238CF@webmail-m289.sysops.aol.com> Message-ID: <20140825150217.GA1582@megas.kitwarein.com> On Mon, Aug 25, 2014 at 10:29:27 -0400, David Cole wrote: > Perhaps, just perhaps, avoiding branch dependencies in the first place > is the proper solution to such a problem, rather than requiring your > review tool to handle it. This usually arises from wide-sweeping changes which uncover other, unrelated bugs in the process. For example, my performance changes for CMake uncovered lots of little things which were a nightmare to review as a single codedrop, but were untestable (in terms of finding new bottlenecks) on my end when they were all independent. This meant it got *developed* as a single monolithic set of changes, but merged as logical commits in grouped and bisectable branches. > Branch dependencies are also hard to handle > from a mental/human perspective -- it's not just the tools -- better to > have independent branches. Or, to wait for the first branch to make it > all the way back to master before starting the second branch. I think this is an artificial stall on my time to have to do this. If I have a train of 3 branches to go in, that could take a week before I could *start* the third versus get it all working at once and get a more high-level view of earlier branches (not to mention it's probably real testing of the earlier branches and bugs get found and fixed earlier this way). One place I see this a lot is ParaView changes which require changes in VTK which are untestable without the ParaView end (see unified-bindings or getting VTK's testing up to par so that ParaView can use the infrastructure as well). Context switching is already expensive; let's not force them because of a tool deficiency if possible. > I know, I know. git was supposed to eliminate the need for patience and > perseverence, right? ;-) Not to my knowledge; just be more flexible to different work styles (of which I'm aware mine is not the most common). > > - Comments are per patch set and not carried over if the commented-on > > code didn't change which makes fixing half the comments on a review > > a pain. > > That is a pain -- but is it handled any better in one of the other > suggested workflows? Github seems to attach comments to commit hashes and/or blob hashes, so a rebase or amend will trash the linkings. Reviewboard *might* be able to do it via its pure-diff orientation, but I'm not completely sure. --Ben From berk.geveci at kitware.com Mon Aug 25 10:53:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 10:53:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Bill, David: Can you provide some details on which parts of the Vanilla Gerrit workflow you like? I'd like to understand if these are unique to the Gerrit tool. As far as I can tell, things that are somewhat unique to this workflow are: 1. Encouragement of very short branches, single changesets preferred, 2. Voting (although bitbucket has something like this too), 3. Assignment of multiple reviewers, 4. Keeping around all revisions of a changeset that were created during the review for future audit (Github does not have this, not clear if others have it) Did I miss anything? Which of these are important to prefer Gerrit over other tools? Best, -berk -berk On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen wrote: > I prefer Vanilla Gerrit. I always liked single commits. And, ITK is > using pretty much the vanilla workflow. > > > On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci > wrote: > > Hi David, > > > > From what I can tell, you can't even get the order of changesets in a > topic > > in vanilla Gerrit. You can search by a topic but that seems to be it for > > topic support. Also, I don't think that there is any way of merging an > > entire topic. That's changeset based too. > > > > So based on what I see, I disagree with " topics in vanilla gerrit really > > aren't that bad" :-) If we were to use Gerrit, I think that we would > have to > > require that branches are squashed to 1 commit except unusual > circumstances. > > > > So a clarification to what I meant by vanilla Gerrit workflow: for the > most > > part, the workflow would require branches of single or at most a few > > commits. Longer running branches with 10s of commits would be a major > pain > > to manage in Gerrit and would probably require special handling. > > > > -berk > > > > > > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi > wrote: > >> > >> I'm all for sticking with gerrit. I'll be sad to lose the topic > >> review interface, but topics in vanilla gerrit really aren't that bad. > >> We'll still be able to push topics and we'll be able to see all the > >> changes that make up a topic. I believe that what we lose is 1) the > >> ability to do a topic-level review and 2) the ability to browse by > >> topic. > >> > >> The only thing that annoys me with gerrit is that when you click > >> "review", it hides all of the previous review comments until you're > >> done. Hopefully the new gerrit has fixed this. > >> > >> The things I'd like to see in a code review system are: > >> > >> - Tight integration with the bugtracker. > >> > >> - Some kind of incentive for reviewers, even if it's just gold stars > >> or a "top reviewer" list. > >> > >> Or we could be draconian and enforce a review/submit ratio, just like > >> the old BBS's enforced upload/download ratios. > >> > >> - David > > > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > 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 ben.boeckel at kitware.com Mon Aug 25 11:05:58 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 11:05:58 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <193DE14C-11B3-43B8-B611-4F9A6925DEDE@kitware.com> <20140825123825.GA512@megas.kitwarein.com> <8D18E87738F0C6E-1E58-23881@webmail-m289.sysops.aol.com> Message-ID: <20140825150558.GB1582@megas.kitwarein.com> On Mon, Aug 25, 2014 at 10:24:44 -0400, David Cole wrote: > > When viewing a diff, you can click "Patch Sets" at the top to get a > > bunch of radio buttons to choose the old/new revision to view. > > That's exactly the view that gets messed up when somebody does a rebase > in between patch sets. It's only useful all the time if everybody > agrees to avoid rebasing changesets. Ah, you mean rebase on a different merge-base. When working on branches, I have a script (git-remake; see below) which will rebase on the same merge-base so that the branch is rooted to the same spot, but the commits change. Adding --fork-point for recent-enough git versions (1.9.x?) to the merge-base calculation is recommended for branches which have master merged back into it. --Ben ======= git-remake ======= #!/bin/sh base="${1:-master}" shift exec git rebase -i --autosquash "$@" "$( git merge-base HEAD "$base" )" From utkarsh.ayachit at kitware.com Mon Aug 25 13:24:31 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 13:24:31 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: As I was reading this I tried to mull on why I don't like our current gerrit to see if that'd help me figure out what my vote would be. We want to adopt the same workflow for ParaView too, and I'm afraid squashing all commits into a single commit just doesn't work the several of changes which are core and critical to the evolution of the software. Thus for my personal sake, squashing to a single commit is a non-starter. For the most part, VTK-gerrit does everything I'd want it to do. All my complaints are really user-interface related -- I'm sure everyone has run into them so there's no point hashing those out here. I started looking around for what other gerrit review users are doing and I was pleasantly surprised, on the face. I see that most other gerrit pages look much nicer and cleaner than ours. e.g. https://codereview.qt-project.org/#/q/status:open,n,z https://review.openstack.org/#/q/status:open,n,z http://review.couchbase.org/#/q/status:open,n,z https://gwt-review.googlesource.com/#/q/status:open As I understand, we're using a very old version of gerrit since we had to add support for topic branches. Several of the UI issues do indeed stem from interacting with topic branches. Looking for topic branches in gerrit, I found this: https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches Looking at openstack gerrit, we do see support for topic branches too! https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z The notable difference seems that you can't "review" a topic, you "review" commits in a topic", but in essence that's what we do on VTK-gerrit too, anyways. Utkarsh On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci wrote: > Bill, David: Can you provide some details on which parts of the Vanilla > Gerrit workflow you like? I'd like to understand if these are unique to the > Gerrit tool. As far as I can tell, things that are somewhat unique to this > workflow are: > > 1. Encouragement of very short branches, single changesets preferred, > 2. Voting (although bitbucket has something like this too), > 3. Assignment of multiple reviewers, > 4. Keeping around all revisions of a changeset that were created during > the review for future audit (Github does not have this, not clear if others > have it) > > Did I miss anything? Which of these are important to prefer Gerrit over > other tools? > > Best, > -berk > > > > > > -berk > > > On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen > wrote: > >> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >> using pretty much the vanilla workflow. >> >> >> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >> wrote: >> > Hi David, >> > >> > From what I can tell, you can't even get the order of changesets in a >> topic >> > in vanilla Gerrit. You can search by a topic but that seems to be it for >> > topic support. Also, I don't think that there is any way of merging an >> > entire topic. That's changeset based too. >> > >> > So based on what I see, I disagree with " topics in vanilla gerrit >> really >> > aren't that bad" :-) If we were to use Gerrit, I think that we would >> have to >> > require that branches are squashed to 1 commit except unusual >> circumstances. >> > >> > So a clarification to what I meant by vanilla Gerrit workflow: for the >> most >> > part, the workflow would require branches of single or at most a few >> > commits. Longer running branches with 10s of commits would be a major >> pain >> > to manage in Gerrit and would probably require special handling. >> > >> > -berk >> > >> > >> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >> wrote: >> >> >> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >> >> review interface, but topics in vanilla gerrit really aren't that bad. >> >> We'll still be able to push topics and we'll be able to see all the >> >> changes that make up a topic. I believe that what we lose is 1) the >> >> ability to do a topic-level review and 2) the ability to browse by >> >> topic. >> >> >> >> The only thing that annoys me with gerrit is that when you click >> >> "review", it hides all of the previous review comments until you're >> >> done. Hopefully the new gerrit has fixed this. >> >> >> >> The things I'd like to see in a code review system are: >> >> >> >> - Tight integration with the bugtracker. >> >> >> >> - Some kind of incentive for reviewers, even if it's just gold stars >> >> or a "top reviewer" list. >> >> >> >> Or we could be draconian and enforce a review/submit ratio, just like >> >> the old BBS's enforced upload/download ratios. >> >> >> >> - David >> > >> > >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> 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 > > 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 Mon Aug 25 14:30:11 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 25 Aug 2014 14:30:11 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: <20140825183011.GD29192@megas.kitwarein.com> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > The notable difference seems that you can't "review" a topic, you "review" > commits in a topic", but in essence that's what we do on VTK-gerrit too, > anyways. I think branch-level comments and such are useful (how to test it, why the branch exists, etc.), but we've been without them for a while, so I guess it'd be a high, IMO, Nice To Have?. --Ben From utkarsh.ayachit at kitware.com Mon Aug 25 14:32:48 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 14:32:48 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825183011.GD29192@megas.kitwarein.com> References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: Just looking at a topic discussion in github ( https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do most of what gerrit does, but in prettier/nicer way. In which case I think moving to github would be my vote. Also we can easily integrate documentation, bug tracker etc. -- so wiki's can slowly fade away! Utkarsh On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel wrote: > On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > > The notable difference seems that you can't "review" a topic, you > "review" > > commits in a topic", but in essence that's what we do on VTK-gerrit too, > > anyways. > > I think branch-level comments and such are useful (how to test it, why > the branch exists, etc.), but we've been without them for a while, so I > guess it'd be a high, IMO, Nice To Have?. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Mon Aug 25 14:34:53 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 14:34:53 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: I encourage everyone to think in terms of the workflow(s) that we prefer rather than tools. If we start with "can we live with vanilla gerrit", the answer is going to be yes for most people. However, this is only part of the picture. Some folks mentioned bug tracker integration, others support for rich content such as markdown etc. Integration with cdash @ home is an obvious one. These are good examples of what we want in workflows. Once we have a decent understanding of what people want the workflow to be, we can discuss tools more deeply. So I am interpreting Utkarsh's email as "Thus for my personal sake, squashing to a single commit is a non-starter". And yes, we can manage multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's workflow requirements using pretty much any other tool be it Github/Gitlab/Bitbucket or even mailing list. Since we have to migrate, let's use it as an opportunity and think about upgrading our overall workflow. -berk On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > As I was reading this I tried to mull on why I don't like our current > gerrit to see if that'd help me figure out what my vote would be. > > We want to adopt the same workflow for ParaView too, and I'm afraid > squashing all commits into a single commit just doesn't work the several of > changes which are core and critical to the evolution of the software. Thus > for my personal sake, squashing to a single commit is a non-starter. > > For the most part, VTK-gerrit does everything I'd want it to do. All my > complaints are really user-interface related -- I'm sure everyone has run > into them so there's no point hashing those out here. I started looking > around for what other gerrit review users are doing and I was pleasantly > surprised, on the face. I see that most other gerrit pages look much nicer > and cleaner than ours. > e.g. > > https://codereview.qt-project.org/#/q/status:open,n,z > https://review.openstack.org/#/q/status:open,n,z > http://review.couchbase.org/#/q/status:open,n,z > https://gwt-review.googlesource.com/#/q/status:open > > As I understand, we're using a very old version of gerrit since we had to > add support for topic branches. Several of the UI issues do indeed stem > from interacting with topic branches. Looking for topic branches in gerrit, > I found this: > https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches > > Looking at openstack gerrit, we do see support for topic branches too! > > > https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z > > The notable difference seems that you can't "review" a topic, you "review" > commits in a topic", but in essence that's what we do on VTK-gerrit too, > anyways. > > Utkarsh > > > > > On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci > wrote: > >> Bill, David: Can you provide some details on which parts of the Vanilla >> Gerrit workflow you like? I'd like to understand if these are unique to the >> Gerrit tool. As far as I can tell, things that are somewhat unique to this >> workflow are: >> >> 1. Encouragement of very short branches, single changesets preferred, >> 2. Voting (although bitbucket has something like this too), >> 3. Assignment of multiple reviewers, >> 4. Keeping around all revisions of a changeset that were created during >> the review for future audit (Github does not have this, not clear if others >> have it) >> >> Did I miss anything? Which of these are important to prefer Gerrit over >> other tools? >> >> Best, >> -berk >> >> >> >> >> >> -berk >> >> >> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >> wrote: >> >>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>> using pretty much the vanilla workflow. >>> >>> >>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>> wrote: >>> > Hi David, >>> > >>> > From what I can tell, you can't even get the order of changesets in a >>> topic >>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>> for >>> > topic support. Also, I don't think that there is any way of merging an >>> > entire topic. That's changeset based too. >>> > >>> > So based on what I see, I disagree with " topics in vanilla gerrit >>> really >>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>> have to >>> > require that branches are squashed to 1 commit except unusual >>> circumstances. >>> > >>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>> most >>> > part, the workflow would require branches of single or at most a few >>> > commits. Longer running branches with 10s of commits would be a major >>> pain >>> > to manage in Gerrit and would probably require special handling. >>> > >>> > -berk >>> > >>> > >>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>> wrote: >>> >> >>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>> >> review interface, but topics in vanilla gerrit really aren't that bad. >>> >> We'll still be able to push topics and we'll be able to see all the >>> >> changes that make up a topic. I believe that what we lose is 1) the >>> >> ability to do a topic-level review and 2) the ability to browse by >>> >> topic. >>> >> >>> >> The only thing that annoys me with gerrit is that when you click >>> >> "review", it hides all of the previous review comments until you're >>> >> done. Hopefully the new gerrit has fixed this. >>> >> >>> >> The things I'd like to see in a code review system are: >>> >> >>> >> - Tight integration with the bugtracker. >>> >> >>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>> >> or a "top reviewer" list. >>> >> >>> >> Or we could be draconian and enforce a review/submit ratio, just like >>> >> the old BBS's enforced upload/download ratios. >>> >> >>> >> - David >>> > >>> > >>> > >>> > _______________________________________________ >>> > Powered by www.kitware.com >>> > >>> > Visit other Kitware open-source projects at >>> > http://www.kitware.com/opensource/opensource.html >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>> > >>> > >>> >>> >>> >>> -- >>> 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 >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Mon Aug 25 14:38:01 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Mon, 25 Aug 2014 14:38:01 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > Just looking at a topic discussion in github ( > https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do > most of what gerrit does, but in prettier/nicer way. In which case I think > moving to github would be my vote. Also we can easily integrate > documentation, bug tracker etc. -- so wiki's can slowly fade away! > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long discussion). I think its simple enough. I think it covers the basic features we need in a reasonable easy to use manner. Also, as I know that github team is working on improving it further in the future (more features). - Aashish > > Utkarsh > > > > > On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel > wrote: > >> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: >> > The notable difference seems that you can't "review" a topic, you >> "review" >> > commits in a topic", but in essence that's what we do on VTK-gerrit too, >> > anyways. >> >> I think branch-level comments and such are useful (how to test it, why >> the branch exists, etc.), but we've been without them for a while, so I >> guess it'd be a high, IMO, Nice To Have?. >> >> --Ben >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 robert.maynard at kitware.com Mon Aug 25 15:12:35 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 25 Aug 2014 15:12:35 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: On a side topic. I know that CDash restful API has been improved lately, so now we can integrate CDash reports into commenting systems. For example I have a proof of concept here: https://github.com/robertmaynard/Remus/pull/108 . Github/Gitlab both have a great web service hook system that should allow us to initiate builds from pull requests. On Mon, Aug 25, 2014 at 2:38 PM, Aashish Chaudhary wrote: > On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit > wrote: >> >> Just looking at a topic discussion in github ( >> https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can do >> most of what gerrit does, but in prettier/nicer way. In which case I think >> moving to github would be my vote. Also we can easily integrate >> documentation, bug tracker etc. -- so wiki's can slowly fade away! > > > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long > discussion). I think its simple enough. I think it covers the basic features > we need in a reasonable easy to use manner. Also, as I know that github team > is working on improving it further in the future (more features). > > - Aashish > >> >> >> Utkarsh >> >> >> >> >> On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel >> wrote: >>> >>> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: >>> > The notable difference seems that you can't "review" a topic, you >>> > "review" >>> > commits in a topic", but in essence that's what we do on VTK-gerrit >>> > too, >>> > anyways. >>> >>> I think branch-level comments and such are useful (how to test it, why >>> the branch exists, etc.), but we've been without them for a while, so I >>> guess it'd be a high, IMO, Nice To Have?. >>> >>> --Ben >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From utkarsh.ayachit at kitware.com Mon Aug 25 15:19:06 2014 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 25 Aug 2014 15:19:06 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> <20140825183011.GD29192@megas.kitwarein.com> Message-ID: Very cool! On Mon, Aug 25, 2014 at 3:12 PM, Robert Maynard wrote: > On a side topic. I know that CDash restful API has been improved > lately, so now we can integrate CDash reports into commenting systems. > For example I have a proof of concept here: > https://github.com/robertmaynard/Remus/pull/108 . Github/Gitlab both > have a great web service hook system that should allow us to initiate > builds from pull requests. > > > On Mon, Aug 25, 2014 at 2:38 PM, Aashish Chaudhary > wrote: > > On Mon, Aug 25, 2014 at 2:32 PM, Utkarsh Ayachit > > wrote: > >> > >> Just looking at a topic discussion in github ( > >> https://github.com/OpenGeoscience/geojs/pull/182 ), I see that it can > do > >> most of what gerrit does, but in prettier/nicer way. In which case I > think > >> moving to github would be my vote. Also we can easily integrate > >> documentation, bug tracker etc. -- so wiki's can slowly fade away! > > > > > > +1. We have adopted it for GeoJS and soon for UV-CDAT (after a long > > discussion). I think its simple enough. I think it covers the basic > features > > we need in a reasonable easy to use manner. Also, as I know that github > team > > is working on improving it further in the future (more features). > > > > - Aashish > > > >> > >> > >> Utkarsh > >> > >> > >> > >> > >> On Mon, Aug 25, 2014 at 2:30 PM, Ben Boeckel > >> wrote: > >>> > >>> On Mon, Aug 25, 2014 at 13:24:31 -0400, Utkarsh Ayachit wrote: > >>> > The notable difference seems that you can't "review" a topic, you > >>> > "review" > >>> > commits in a topic", but in essence that's what we do on VTK-gerrit > >>> > too, > >>> > anyways. > >>> > >>> I think branch-level comments and such are useful (how to test it, why > >>> the branch exists, etc.), but we've been without them for a while, so I > >>> guess it'd be a high, IMO, Nice To Have?. > >>> > >>> --Ben > >> > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Aug 25 15:27:55 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 25 Aug 2014 15:27:55 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: My preferred workflow as a developer would be: 1. Create a topic / pull request. 2. I assign people to review topic 3. Automatic integration builds start going to work. 4. Something reports back to the status of the build and tests, which notifies the author and reviewers that building and testing have finished. 5. Reviewers decide based on code and build status if code is worth merging. When changes happen: 1. I extend the topic with fixes based on review or integration tests, or squash changes back into the original topic as they are style/spelling issues. 2. Automatic integration starts up again 3. The commenters are notified that author has modified the topic 4. Commenters can easily see the difference between the old and new versions. As a reviewer I desire a different set of features: 1. Ability to comment inline with the code 2. Easy way to generate a single view of all the changes for a topic 3. Ability to easily see if the topic has broken the build or tests. 5. A way to force a re-build or re-test of a topic incase I believe something was caused by a machine failure 6. Ability to bring other people into the conversation. Be it through '@' tags or adding people as reviewers. 7. Ability to get emails on a per project / topic level On Mon, Aug 25, 2014 at 2:34 PM, Berk Geveci wrote: > I encourage everyone to think in terms of the workflow(s) that we prefer > rather than tools. If we start with "can we live with vanilla gerrit", the > answer is going to be yes for most people. However, this is only part of the > picture. Some folks mentioned bug tracker integration, others support for > rich content such as markdown etc. Integration with cdash @ home is an > obvious one. These are good examples of what we want in workflows. Once we > have a decent understanding of what people want the workflow to be, we can > discuss tools more deeply. > > So I am interpreting Utkarsh's email as "Thus for my personal sake, > squashing to a single commit is a non-starter". And yes, we can manage > multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's > workflow requirements using pretty much any other tool be it > Github/Gitlab/Bitbucket or even mailing list. > > Since we have to migrate, let's use it as an opportunity and think about > upgrading our overall workflow. > > -berk > > > On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit > wrote: >> >> As I was reading this I tried to mull on why I don't like our current >> gerrit to see if that'd help me figure out what my vote would be. >> >> We want to adopt the same workflow for ParaView too, and I'm afraid >> squashing all commits into a single commit just doesn't work the several of >> changes which are core and critical to the evolution of the software. Thus >> for my personal sake, squashing to a single commit is a non-starter. >> >> For the most part, VTK-gerrit does everything I'd want it to do. All my >> complaints are really user-interface related -- I'm sure everyone has run >> into them so there's no point hashing those out here. I started looking >> around for what other gerrit review users are doing and I was pleasantly >> surprised, on the face. I see that most other gerrit pages look much nicer >> and cleaner than ours. >> e.g. >> >> https://codereview.qt-project.org/#/q/status:open,n,z >> https://review.openstack.org/#/q/status:open,n,z >> http://review.couchbase.org/#/q/status:open,n,z >> https://gwt-review.googlesource.com/#/q/status:open >> >> As I understand, we're using a very old version of gerrit since we had to >> add support for topic branches. Several of the UI issues do indeed stem from >> interacting with topic branches. Looking for topic branches in gerrit, I >> found this: >> https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches >> >> Looking at openstack gerrit, we do see support for topic branches too! >> >> >> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z >> >> The notable difference seems that you can't "review" a topic, you "review" >> commits in a topic", but in essence that's what we do on VTK-gerrit too, >> anyways. >> >> Utkarsh >> >> >> >> >> On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci >> wrote: >>> >>> Bill, David: Can you provide some details on which parts of the Vanilla >>> Gerrit workflow you like? I'd like to understand if these are unique to the >>> Gerrit tool. As far as I can tell, things that are somewhat unique to this >>> workflow are: >>> >>> 1. Encouragement of very short branches, single changesets preferred, >>> 2. Voting (although bitbucket has something like this too), >>> 3. Assignment of multiple reviewers, >>> 4. Keeping around all revisions of a changeset that were created during >>> the review for future audit (Github does not have this, not clear if others >>> have it) >>> >>> Did I miss anything? Which of these are important to prefer Gerrit over >>> other tools? >>> >>> Best, >>> -berk >>> >>> >>> >>> >>> >>> -berk >>> >>> >>> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >>> wrote: >>>> >>>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>>> using pretty much the vanilla workflow. >>>> >>>> >>>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>>> wrote: >>>> > Hi David, >>>> > >>>> > From what I can tell, you can't even get the order of changesets in a >>>> > topic >>>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>>> > for >>>> > topic support. Also, I don't think that there is any way of merging an >>>> > entire topic. That's changeset based too. >>>> > >>>> > So based on what I see, I disagree with " topics in vanilla gerrit >>>> > really >>>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>>> > have to >>>> > require that branches are squashed to 1 commit except unusual >>>> > circumstances. >>>> > >>>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>>> > most >>>> > part, the workflow would require branches of single or at most a few >>>> > commits. Longer running branches with 10s of commits would be a major >>>> > pain >>>> > to manage in Gerrit and would probably require special handling. >>>> > >>>> > -berk >>>> > >>>> > >>>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>>> > wrote: >>>> >> >>>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>>> >> review interface, but topics in vanilla gerrit really aren't that >>>> >> bad. >>>> >> We'll still be able to push topics and we'll be able to see all the >>>> >> changes that make up a topic. I believe that what we lose is 1) the >>>> >> ability to do a topic-level review and 2) the ability to browse by >>>> >> topic. >>>> >> >>>> >> The only thing that annoys me with gerrit is that when you click >>>> >> "review", it hides all of the previous review comments until you're >>>> >> done. Hopefully the new gerrit has fixed this. >>>> >> >>>> >> The things I'd like to see in a code review system are: >>>> >> >>>> >> - Tight integration with the bugtracker. >>>> >> >>>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>>> >> or a "top reviewer" list. >>>> >> >>>> >> Or we could be draconian and enforce a review/submit ratio, just like >>>> >> the old BBS's enforced upload/download ratios. >>>> >> >>>> >> - David >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Powered by www.kitware.com >>>> > >>>> > Visit other Kitware open-source projects at >>>> > http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From dlrdave at aol.com Mon Aug 25 15:50:59 2014 From: dlrdave at aol.com (David Cole) Date: Mon, 25 Aug 2014 15:50:59 -0400 (EDT) Subject: [vtk-developers] VTK code review / testing / integration workflow Message-ID: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> > My preferred workflow as a developer would be: > ... > 2. I assign people to review topic > ... +1 all the way -- this sounds like a fantastic workflow. One additional requirement I would impose on the workflow is that automatic build/test kickoff only be allowed by requests from a list of trusted individuals. If you're not on the list, you have to ask somebody who is on the list to kick it off for you. A fantasy feature for me would be that the system injects a step 1.5/2.5 in the developer workflow, and automatically chooses 3-5 reviewers for you based on reviewers "signing up" for reviewing certain modules, or perhaps based on recent-ish commits in the same files... Also, one more: it would be nice to have the merge be automatic as soon as it's "approved." (extension to Rob's Dev workflow: Step 6. Automatic merge upon approval.) David C. From bill.lorensen at gmail.com Mon Aug 25 16:28:45 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 16:28:45 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <1EB5880E-E230-4CA3-804E-4222DDC24468@kitware.com> Message-ID: Robert, A +1. To me it looks like our current gerrit workflow. On Mon, Aug 25, 2014 at 3:27 PM, Robert Maynard wrote: > My preferred workflow as a developer would be: > > 1. Create a topic / pull request. > 2. I assign people to review topic > 3. Automatic integration builds start going to work. > 4. Something reports back to the status of the build and tests, which > notifies the author > and reviewers that building and testing have finished. > 5. Reviewers decide based on code and build status if code is worth merging. > > When changes happen: > 1. I extend the topic with fixes based on review or integration tests, > or squash changes back > into the original topic as they are style/spelling issues. > 2. Automatic integration starts up again > 3. The commenters are notified that author has modified the topic > 4. Commenters can easily see the difference between the old and new versions. > > > As a reviewer I desire a different set of features: > > 1. Ability to comment inline with the code > 2. Easy way to generate a single view of all the changes for a topic > 3. Ability to easily see if the topic has broken the build or tests. > 5. A way to force a re-build or re-test of a topic incase I believe something > was caused by a machine failure > 6. Ability to bring other people into the conversation. Be it through > '@' tags or > adding people as reviewers. > 7. Ability to get emails on a per project / topic level > > > On Mon, Aug 25, 2014 at 2:34 PM, Berk Geveci wrote: >> I encourage everyone to think in terms of the workflow(s) that we prefer >> rather than tools. If we start with "can we live with vanilla gerrit", the >> answer is going to be yes for most people. However, this is only part of the >> picture. Some folks mentioned bug tracker integration, others support for >> rich content such as markdown etc. Integration with cdash @ home is an >> obvious one. These are good examples of what we want in workflows. Once we >> have a decent understanding of what people want the workflow to be, we can >> discuss tools more deeply. >> >> So I am interpreting Utkarsh's email as "Thus for my personal sake, >> squashing to a single commit is a non-starter". And yes, we can manage >> multiple changeset topics in Gerrit. But we can also satisfy Utkarsh's >> workflow requirements using pretty much any other tool be it >> Github/Gitlab/Bitbucket or even mailing list. >> >> Since we have to migrate, let's use it as an opportunity and think about >> upgrading our overall workflow. >> >> -berk >> >> >> On Mon, Aug 25, 2014 at 1:24 PM, Utkarsh Ayachit >> wrote: >>> >>> As I was reading this I tried to mull on why I don't like our current >>> gerrit to see if that'd help me figure out what my vote would be. >>> >>> We want to adopt the same workflow for ParaView too, and I'm afraid >>> squashing all commits into a single commit just doesn't work the several of >>> changes which are core and critical to the evolution of the software. Thus >>> for my personal sake, squashing to a single commit is a non-starter. >>> >>> For the most part, VTK-gerrit does everything I'd want it to do. All my >>> complaints are really user-interface related -- I'm sure everyone has run >>> into them so there's no point hashing those out here. I started looking >>> around for what other gerrit review users are doing and I was pleasantly >>> surprised, on the face. I see that most other gerrit pages look much nicer >>> and cleaner than ours. >>> e.g. >>> >>> https://codereview.qt-project.org/#/q/status:open,n,z >>> https://review.openstack.org/#/q/status:open,n,z >>> http://review.couchbase.org/#/q/status:open,n,z >>> https://gwt-review.googlesource.com/#/q/status:open >>> >>> As I understand, we're using a very old version of gerrit since we had to >>> add support for topic branches. Several of the UI issues do indeed stem from >>> interacting with topic branches. Looking for topic branches in gerrit, I >>> found this: >>> https://wiki.openstack.org/wiki/Gerrit_Workflow#Long-lived_Topic_Branches >>> >>> Looking at openstack gerrit, we do see support for topic branches too! >>> >>> >>> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z >>> >>> The notable difference seems that you can't "review" a topic, you "review" >>> commits in a topic", but in essence that's what we do on VTK-gerrit too, >>> anyways. >>> >>> Utkarsh >>> >>> >>> >>> >>> On Mon, Aug 25, 2014 at 10:53 AM, Berk Geveci >>> wrote: >>>> >>>> Bill, David: Can you provide some details on which parts of the Vanilla >>>> Gerrit workflow you like? I'd like to understand if these are unique to the >>>> Gerrit tool. As far as I can tell, things that are somewhat unique to this >>>> workflow are: >>>> >>>> 1. Encouragement of very short branches, single changesets preferred, >>>> 2. Voting (although bitbucket has something like this too), >>>> 3. Assignment of multiple reviewers, >>>> 4. Keeping around all revisions of a changeset that were created during >>>> the review for future audit (Github does not have this, not clear if others >>>> have it) >>>> >>>> Did I miss anything? Which of these are important to prefer Gerrit over >>>> other tools? >>>> >>>> Best, >>>> -berk >>>> >>>> >>>> >>>> >>>> >>>> -berk >>>> >>>> >>>> On Sun, Aug 24, 2014 at 12:52 PM, Bill Lorensen >>>> wrote: >>>>> >>>>> I prefer Vanilla Gerrit. I always liked single commits. And, ITK is >>>>> using pretty much the vanilla workflow. >>>>> >>>>> >>>>> On Sun, Aug 24, 2014 at 8:37 AM, Berk Geveci >>>>> wrote: >>>>> > Hi David, >>>>> > >>>>> > From what I can tell, you can't even get the order of changesets in a >>>>> > topic >>>>> > in vanilla Gerrit. You can search by a topic but that seems to be it >>>>> > for >>>>> > topic support. Also, I don't think that there is any way of merging an >>>>> > entire topic. That's changeset based too. >>>>> > >>>>> > So based on what I see, I disagree with " topics in vanilla gerrit >>>>> > really >>>>> > aren't that bad" :-) If we were to use Gerrit, I think that we would >>>>> > have to >>>>> > require that branches are squashed to 1 commit except unusual >>>>> > circumstances. >>>>> > >>>>> > So a clarification to what I meant by vanilla Gerrit workflow: for the >>>>> > most >>>>> > part, the workflow would require branches of single or at most a few >>>>> > commits. Longer running branches with 10s of commits would be a major >>>>> > pain >>>>> > to manage in Gerrit and would probably require special handling. >>>>> > >>>>> > -berk >>>>> > >>>>> > >>>>> > On Sat, Aug 23, 2014 at 10:18 PM, David Gobbi >>>>> > wrote: >>>>> >> >>>>> >> I'm all for sticking with gerrit. I'll be sad to lose the topic >>>>> >> review interface, but topics in vanilla gerrit really aren't that >>>>> >> bad. >>>>> >> We'll still be able to push topics and we'll be able to see all the >>>>> >> changes that make up a topic. I believe that what we lose is 1) the >>>>> >> ability to do a topic-level review and 2) the ability to browse by >>>>> >> topic. >>>>> >> >>>>> >> The only thing that annoys me with gerrit is that when you click >>>>> >> "review", it hides all of the previous review comments until you're >>>>> >> done. Hopefully the new gerrit has fixed this. >>>>> >> >>>>> >> The things I'd like to see in a code review system are: >>>>> >> >>>>> >> - Tight integration with the bugtracker. >>>>> >> >>>>> >> - Some kind of incentive for reviewers, even if it's just gold stars >>>>> >> or a "top reviewer" list. >>>>> >> >>>>> >> Or we could be draconian and enforce a review/submit ratio, just like >>>>> >> the old BBS's enforced upload/download ratios. >>>>> >> >>>>> >> - David >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Powered by www.kitware.com >>>>> > >>>>> > Visit other Kitware open-source projects at >>>>> > http://www.kitware.com/opensource/opensource.html >>>>> > >>>>> > Follow this link to subscribe/unsubscribe: >>>>> > http://public.kitware.com/mailman/listinfo/vtk-developers >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>>> 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 >> >> 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From sean at rogue-research.com Mon Aug 25 16:45:30 2014 From: sean at rogue-research.com (Sean McBride) Date: Mon, 25 Aug 2014 16:45:30 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> Message-ID: <20140825204530.1173865063@mail.rogue-research.com> On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >A fantasy feature for me would be that the system injects a step >1.5/2.5 in the developer workflow, and automatically chooses 3-5 >reviewers for you based on reviewers "signing up" for reviewing certain >modules, or perhaps based on recent-ish commits in the same files... That would be a great addition. I often don't know who to add as a reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A person can use 'git log' and 'git blame' to get some guesses, and that could be automated. Of course, sometimes that results in suggesting someone no longer involved with VTK or the infamous 'VTK developers', but still it would help to automate it. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.lorensen at gmail.com Mon Aug 25 16:54:16 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 16:54:16 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <20140825204530.1173865063@mail.rogue-research.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: BTW the new gerrit UI is a bit prettier: https://android-review.googlesource.com/#/q/status:open I'm a little concerned that we spend too much time on process and not enough time on improving VTK. But, I'll go with the consensus of the people who still work for a living. If the new process is too difficult for an old guy like me, I'll just spend my extra time with ITK. Bill On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride wrote: > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: > >>A fantasy feature for me would be that the system injects a step >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >>reviewers for you based on reviewers "signing up" for reviewing certain >>modules, or perhaps based on recent-ish commits in the same files... > > That would be a great addition. I often don't know who to add as a reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A person can use 'git log' and 'git blame' to get some guesses, and that could be automated. Of course, sometimes that results in suggesting someone no longer involved with VTK or the infamous 'VTK developers', but still it would help to automate it. > > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Mon Aug 25 19:47:10 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 25 Aug 2014 19:47:10 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Hi Bill, The goal is not to have more process. It is to implement a workflow with fun-to-use tools such that we can continue to attract developers to VTK. VTK development is lively. We have done a lot of great stuff last year, both new development and maintenance, and we have great things coming next year. In my humble opinion, what we are doing poorly is attracting new developers. I think toolchain and workflow play a role in this. Not communicating well is another part. I'd like to attract more people to contribute code and more people to do reviews. Also, our bug tracker is collecting dust. Lots of bug reports are going in but it gets very little attention. I can't even remember when I looked at it last. Here are some statistics from openhub.net (website formerly known as ohloh): VTK: 30 Day Summary Jul 21 2014 ? Aug 20 2014 152 Commits 19 Contributors 12 Month Summary Aug 20 2013 ? Aug 20 2014 2393 Commits Down -965 (28%) from previous 12 months 64 Contributors Down -6 (8%) from previous 12 months Still a lot of commits but going down. So I'd like to see us slowly migrating towards tools that are more attractive and facilitate collaboration with the larger community. Frankly, I believe that our current set of tools get in the way. First of all, they all require creating accounts to do anything. An account for bug tracker, another for Gerrit, another for Wiki, another 2 for the mailing lists. We should have presence where people already hang out and don't have to create new accounts. Github, stackoverflow, Google+ etc. Second of all, they are all clunky at best. Usability does matter to people. Finally, there are a lot new resources available out there and we are not tapping into it as best as we can. We should be using Travis and Jenkins in addition to CDash and CDash @ Home for example. So I don't think that this conversation is overkill. These discussions have a natural tendency to go on forever, I agree. So let's try to keep to the point and make some decisions soon. Best, -berk On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen wrote: > BTW the new gerrit UI is a bit prettier: > https://android-review.googlesource.com/#/q/status:open > > I'm a little concerned that we spend too much time on process and not > enough time on improving VTK. But, I'll go with the consensus of the > people who still work for a living. If the new process is too > difficult for an old guy like me, I'll just spend my extra time with > ITK. > > Bill > > > On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride > wrote: > > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: > > > >>A fantasy feature for me would be that the system injects a step > >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 > >>reviewers for you based on reviewers "signing up" for reviewing certain > >>modules, or perhaps based on recent-ish commits in the same files... > > > > That would be a great addition. I often don't know who to add as a > reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A > person can use 'git log' and 'git blame' to get some guesses, and that > could be automated. Of course, sometimes that results in suggesting > someone no longer involved with VTK or the infamous 'VTK developers', but > still it would help to automate it. > > > > 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 > > > > 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 david.gobbi at gmail.com Mon Aug 25 19:55:04 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 25 Aug 2014 17:55:04 -0600 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: In general, I'd be happy with pretty much any tool, even the linux method of doing everything via email sounds fine to me. Getting back to workflow, here are the only things that I see as absolutely essential: - mandatory testing prior to merge - mandatory review and approval - reviews must be taken seriously by all parties, they're not just a hoop to jump through Here are additional workflow steps that I'd like to see: - a lightweight proposal process for large changes - all reported bugs should be assessed and assigned For bugs, ideally all developers should watch the bugtracker, but it might be necessary for there to be a developer assigned to watching for reports. We're never going to grow our community if we ignore bug reports (or if we consistently ignore questions on the mailing list). - David From bill.lorensen at gmail.com Mon Aug 25 21:17:46 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 25 Aug 2014 21:17:46 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Berk, If the goal is to attract more developers then we need to understand why we are not attracting them. We should not assume that changing our process is a solution. I think the process discussion is a good one, but it may not be the core issue. I suggest we start another thread to address the developer issue. Bill On Aug 25, 2014 7:47 PM, "Berk Geveci" wrote: > Hi Bill, > > The goal is not to have more process. It is to implement a workflow with > fun-to-use tools such that we can continue to attract developers to VTK. > VTK development is lively. We have done a lot of great stuff last year, > both new development and maintenance, and we have great things coming next > year. > > In my humble opinion, what we are doing poorly is attracting new > developers. I think toolchain and workflow play a role in this. Not > communicating well is another part. I'd like to attract more people to > contribute code and more people to do reviews. Also, our bug tracker is > collecting dust. Lots of bug reports are going in but it gets very little > attention. I can't even remember when I looked at it last. > > Here are some statistics from openhub.net (website formerly known as > ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 ? Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 ? Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First of > all, they all require creating accounts to do anything. An account for bug > tracker, another for Gerrit, another for Wiki, another 2 for the mailing > lists. We should have presence where people already hang out and don't have > to create new accounts. Github, stackoverflow, Google+ etc. Second of all, > they are all clunky at best. Usability does matter to people. Finally, > there are a lot new resources available out there and we are not tapping > into it as best as we can. We should be using Travis and Jenkins in > addition to CDash and CDash @ Home for example. > > So I don't think that this conversation is overkill. These discussions > have a natural tendency to go on forever, I agree. So let's try to keep to > the point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > wrote: > >> BTW the new gerrit UI is a bit prettier: >> https://android-review.googlesource.com/#/q/status:open >> >> I'm a little concerned that we spend too much time on process and not >> enough time on improving VTK. But, I'll go with the consensus of the >> people who still work for a living. If the new process is too >> difficult for an old guy like me, I'll just spend my extra time with >> ITK. >> >> Bill >> >> >> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >> wrote: >> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >> > >> >>A fantasy feature for me would be that the system injects a step >> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >> >>reviewers for you based on reviewers "signing up" for reviewing certain >> >>modules, or perhaps based on recent-ish commits in the same files... >> > >> > That would be a great addition. I often don't know who to add as a >> reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >> person can use 'git log' and 'git blame' to get some guesses, and that >> could be automated. Of course, sometimes that results in suggesting >> someone no longer involved with VTK or the infamous 'VTK developers', but >> still it would help to automate it. >> > >> > 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 >> > >> > 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 burlen.loring at gmail.com Tue Aug 26 12:52:40 2014 From: burlen.loring at gmail.com (Burlen Loring) Date: Tue, 26 Aug 2014 09:52:40 -0700 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: <53FCBB58.5090405@gmail.com> I wanted to comment that your gerrit work flow is great. I like the organization by topic branches and that dashboard runs are automatically triggered on new pushes. Also the reviews by folks on your side have been very helpful in improving the submitted code. It would be nice to see a diff between successive review/recommit iterations. I don't know how much the work flow is turning off new developers, a knee jerk reaction is that it feels like overkill, but all of the things that you ask folks to do make a lot of sense and help keep VTK solid. It sure is rewarding to see how solid VTK is and see it's continual improvement and to be a part of that! As a developer the high quality of the resulting product outs weigh my desire to work with fun tools. I recently made some commits to a KDE component project. Their workflow uses svn+reviewboard. The lack of topic branches made iteration cumbersome. Once the patches were approved merging was not as easy as it is in your gerrit workflow where it's done with a simple button click on a web page. I would think that modernization is more of an issue in attracting developers. Ancient OpenGL infrastructure is a really big one. Things like having to use SafeDownCast instead of dynamic_cast and the other baggage of supporting ancient compilers are also a big turnoff. A full c++11 port would be very exciting. All these are things you are working on but are harder and take longer to change... On 08/25/2014 04:47 PM, Berk Geveci wrote: > Hi Bill, > > The goal is not to have more process. It is to implement a workflow > with fun-to-use tools such that we can continue to attract developers > to VTK. VTK development is lively. We have done a lot of great stuff > last year, both new development and maintenance, and we have great > things coming next year. > > In my humble opinion, what we are doing poorly is attracting new > developers. I think toolchain and workflow play a role in this. Not > communicating well is another part. I'd like to attract more people to > contribute code and more people to do reviews. Also, our bug tracker > is collecting dust. Lots of bug reports are going in but it gets very > little attention. I can't even remember when I looked at it last. > > Here are some statistics from openhub.net > (website formerly known as ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 --- Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 --- Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First > of all, they all require creating accounts to do anything. An account > for bug tracker, another for Gerrit, another for Wiki, another 2 for > the mailing lists. We should have presence where people already hang > out and don't have to create new accounts. Github, stackoverflow, > Google+ etc. Second of all, they are all clunky at best. Usability > does matter to people. Finally, there are a lot new resources > available out there and we are not tapping into it as best as we can. > We should be using Travis and Jenkins in addition to CDash and CDash @ > Home for example. > > So I don't think that this conversation is overkill. These discussions > have a natural tendency to go on forever, I agree. So let's try to > keep to the point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > > wrote: > > BTW the new gerrit UI is a bit prettier: > https://android-review.googlesource.com/#/q/status:open > > I'm a little concerned that we spend too much time on process and not > enough time on improving VTK. But, I'll go with the consensus of the > people who still work for a living. If the new process is too > difficult for an old guy like me, I'll just spend my extra time with > ITK. > > Bill > > > On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride > > wrote: > > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via > vtk-developers said: > > > >>A fantasy feature for me would be that the system injects a step > >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 > >>reviewers for you based on reviewers "signing up" for reviewing > certain > >>modules, or perhaps based on recent-ish commits in the same files... > > > > That would be a great addition. I often don't know who to add > as a reviewer, and I've been tinkering with VTK for years. > Imagine a newbie! A person can use 'git log' and 'git blame' to > get some guesses, and that could be automated. Of course, > sometimes that results in suggesting someone no longer involved > with VTK or the infamous 'VTK developers', but still it would help > to automate it. > > > > 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 > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Aug 26 14:46:25 2014 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 26 Aug 2014 14:46:25 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: <53FCBB58.5090405@gmail.com> References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: This is in the "would be nice to have" category. Based on recent personal experience and the experience of others updating VTK versions, I would like to see performance regression tests in VTK (e.g., changes to memory consumption, execution time, rendering frame rate, etc.) with the results of the tests reported in the review workflow. That way developers and reviewers could easily reject changes that cause unacceptable performance regressions. I realize this might not be the easiest thing to implement, and would require changes beyond the review system, but it would be very nice. CDash reports a history of the execution time of tests, but this isn't always helpful in its current form. - Cory On Tue, Aug 26, 2014 at 12:52 PM, Burlen Loring wrote: > I wanted to comment that your gerrit work flow is great. I like the > organization by topic branches and that dashboard runs are automatically > triggered on new pushes. Also the reviews by folks on your side have been > very helpful in improving the submitted code. It would be nice to see a diff > between successive review/recommit iterations. > > I don't know how much the work flow is turning off new developers, a knee > jerk reaction is that it feels like overkill, but all of the things that you > ask folks to do make a lot of sense and help keep VTK solid. It sure is > rewarding to see how solid VTK is and see it's continual improvement and to > be a part of that! As a developer the high quality of the resulting product > outs weigh my desire to work with fun tools. > > I recently made some commits to a KDE component project. Their workflow uses > svn+reviewboard. The lack of topic branches made iteration cumbersome. Once > the patches were approved merging was not as easy as it is in your gerrit > workflow where it's done with a simple button click on a web page. > > I would think that modernization is more of an issue in attracting > developers. Ancient OpenGL infrastructure is a really big one. Things like > having to use SafeDownCast instead of dynamic_cast and the other baggage of > supporting ancient compilers are also a big turnoff. A full c++11 port would > be very exciting. All these are things you are working on but are harder and > take longer to change... > > > On 08/25/2014 04:47 PM, Berk Geveci wrote: > > Hi Bill, > > The goal is not to have more process. It is to implement a workflow with > fun-to-use tools such that we can continue to attract developers to VTK. VTK > development is lively. We have done a lot of great stuff last year, both new > development and maintenance, and we have great things coming next year. > > In my humble opinion, what we are doing poorly is attracting new developers. > I think toolchain and workflow play a role in this. Not communicating well > is another part. I'd like to attract more people to contribute code and more > people to do reviews. Also, our bug tracker is collecting dust. Lots of bug > reports are going in but it gets very little attention. I can't even > remember when I looked at it last. > > Here are some statistics from openhub.net (website formerly known as ohloh): > > VTK: > > 30 Day Summary > Jul 21 2014 ? Aug 20 2014 > 152 Commits > 19 Contributors > > 12 Month Summary > Aug 20 2013 ? Aug 20 2014 > 2393 Commits > Down -965 (28%) from previous 12 months > 64 Contributors > Down -6 (8%) from previous 12 months > > Still a lot of commits but going down. > > So I'd like to see us slowly migrating towards tools that are more > attractive and facilitate collaboration with the larger community. > > Frankly, I believe that our current set of tools get in the way. First of > all, they all require creating accounts to do anything. An account for bug > tracker, another for Gerrit, another for Wiki, another 2 for the mailing > lists. We should have presence where people already hang out and don't have > to create new accounts. Github, stackoverflow, Google+ etc. Second of all, > they are all clunky at best. Usability does matter to people. Finally, there > are a lot new resources available out there and we are not tapping into it > as best as we can. We should be using Travis and Jenkins in addition to > CDash and CDash @ Home for example. > > So I don't think that this conversation is overkill. These discussions have > a natural tendency to go on forever, I agree. So let's try to keep to the > point and make some decisions soon. > > Best, > -berk > > > > > > > On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen > wrote: >> >> BTW the new gerrit UI is a bit prettier: >> https://android-review.googlesource.com/#/q/status:open >> >> I'm a little concerned that we spend too much time on process and not >> enough time on improving VTK. But, I'll go with the consensus of the >> people who still work for a living. If the new process is too >> difficult for an old guy like me, I'll just spend my extra time with >> ITK. >> >> Bill >> >> >> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >> wrote: >> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >> > >> >>A fantasy feature for me would be that the system injects a step >> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >> >>reviewers for you based on reviewers "signing up" for reviewing certain >> >>modules, or perhaps based on recent-ish commits in the same files... >> > >> > That would be a great addition. I often don't know who to add as a >> > reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >> > person can use 'git log' and 'git blame' to get some guesses, and that could >> > be automated. Of course, sometimes that results in suggesting someone no >> > longer involved with VTK or the infamous 'VTK developers', but still it >> > would help to automate it. >> > >> > 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 >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> >> >> >> -- >> 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 > > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From berk.geveci at kitware.com Tue Aug 26 15:32:27 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 15:32:27 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Here is a summary that I came up with from the discussion so far. Does this look good? Requirements: - Branch / topic based workflow - Automated testing before merge (required to pass) - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) - Automatic notification on change - Ability to comment on the code (Web GUI preferred) - All reported bugs should be assessed and assigned Nice to have: - Tight integration with issue (bug) tracking and release process - Stakeholders for particular pieces identified / in the loop / easy or automatic assignment of reviewers - Ease of use - Incentive for reviewers (goal being encouraging more reviews) - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI - Lightweight proposal process for large changes - Way to track performance regression -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 15:43:34 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 15:43:34 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: +1 and Gerrit seems to support them all. On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci wrote: > Here is a summary that I came up with from the discussion so far. Does this > look good? > > Requirements: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > - All reported bugs should be assessed and assigned > > Nice to have: > > - Tight integration with issue (bug) tracking and release process > - Stakeholders for particular pieces identified / in the loop / easy or > automatic assignment of > reviewers > - Ease of use > - Incentive for reviewers (goal being encouraging more reviews) > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > - Lightweight proposal process for large changes > - Way to track performance regression > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:04:33 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:04:33 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: I disagree. Gerrit does not support any of the "nice to have"s in a straightforward way. Neither does vanilla Gerrit properly support "branch / topic based workflow" in a straightforward way. It supports a changeset based workflow and "branch / topic" based workflows have to be shoehorned into it if a "branch / topic" has more than 1 changeset. Also to support automated testing of branch tips, we would have to create custom scaffolding since vanilla Gerrit has no such concept. Gerrit, with a little help from cdash @ home does a decent job of the following: - Automated testing before merge (required to pass) - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) - Automatic notification on change - Ability to comment on the code (Web GUI preferred) It clearly doesn't do any of this: - Tight integration with issue (bug) tracking and release process - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI In my opinion, it does a very poor job of these: - Branch / topic based workflow - Ease of use The other requirements and nice-to-haves are independent of tools and can be achieved using whatever tool. However, Mantis is also not the easiest tool so replacing it is also a good idea. In my opinion, the biggest weaknesses of Github and Gitlab are: - Assign reviewers to topic - Review / approval before merge (required to pass) - Ability to go back to discussion leading to merge (audit trail) They don't have a clear voting system and are based on more a general discussion workflow. We would have to create some guidelines on how to achieve these in those tools. For example, someone doing a pull request would have to add a comment mentioning potential reviewers with the @name syntax to "assign reviewers". The reviewers would have to use some previously agreed upon language to approve a topic in the discussion. Something like "Approved for merge". Github is far superior to Gerrit in these: - Branch / topic based workflow - Automated testing before merge (required to pass) - tight integration with Travis and demonstrated integration with cdash @ home through custom hooks - Automatic notification on change - much finer notification control - Ability to comment on the code (Web GUI preferred) - go check it out if you don't believe me - Tight integration with issue (bug) tracking and release process - Ease of use - Integration with Wiki - Easy documentation / Markdown /rST support - Easy way to generate single view of all changes in the Web GUI - this is impossible in Gerrit even for a single changeset Best, -berk On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen wrote: > +1 and Gerrit seems to support them all. > > > On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci > wrote: > > Here is a summary that I came up with from the discussion so far. Does > this > > look good? > > > > Requirements: > > > > - Branch / topic based workflow > > - Automated testing before merge (required to pass) > > - Assign reviewers to topic > > - Review / approval before merge (required to pass) > > - Ability to go back to discussion leading to merge (audit trail) > > - Automatic notification on change > > - Ability to comment on the code (Web GUI preferred) > > - All reported bugs should be assessed and assigned > > > > Nice to have: > > > > - Tight integration with issue (bug) tracking and release process > > - Stakeholders for particular pieces identified / in the loop / easy or > > automatic assignment of > > reviewers > > - Ease of use > > - Incentive for reviewers (goal being encouraging more reviews) > > - Integration with Wiki > > - Easy documentation / Markdown /rST support > > - Easy way to generate single view of all changes in the Web GUI > > - Lightweight proposal process for large changes > > - Way to track performance regression > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Aug 26 16:05:22 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:05:22 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> Message-ID: Agreed. I'll start some new threads on this. On Mon, Aug 25, 2014 at 9:17 PM, Bill Lorensen wrote: > Berk, > If the goal is to attract more developers then we need to understand why > we are not attracting them. We should not assume that changing our process > is a solution. I think the process discussion is a good one, but it may not > be the core issue. I suggest we start another thread to address the > developer issue. > > Bill > On Aug 25, 2014 7:47 PM, "Berk Geveci" wrote: > >> Hi Bill, >> >> The goal is not to have more process. It is to implement a workflow with >> fun-to-use tools such that we can continue to attract developers to VTK. >> VTK development is lively. We have done a lot of great stuff last year, >> both new development and maintenance, and we have great things coming next >> year. >> >> In my humble opinion, what we are doing poorly is attracting new >> developers. I think toolchain and workflow play a role in this. Not >> communicating well is another part. I'd like to attract more people to >> contribute code and more people to do reviews. Also, our bug tracker is >> collecting dust. Lots of bug reports are going in but it gets very little >> attention. I can't even remember when I looked at it last. >> >> Here are some statistics from openhub.net (website formerly known as >> ohloh): >> >> VTK: >> >> 30 Day Summary >> Jul 21 2014 ? Aug 20 2014 >> 152 Commits >> 19 Contributors >> >> 12 Month Summary >> Aug 20 2013 ? Aug 20 2014 >> 2393 Commits >> Down -965 (28%) from previous 12 months >> 64 Contributors >> Down -6 (8%) from previous 12 months >> >> Still a lot of commits but going down. >> >> So I'd like to see us slowly migrating towards tools that are more >> attractive and facilitate collaboration with the larger community. >> >> Frankly, I believe that our current set of tools get in the way. First of >> all, they all require creating accounts to do anything. An account for bug >> tracker, another for Gerrit, another for Wiki, another 2 for the mailing >> lists. We should have presence where people already hang out and don't have >> to create new accounts. Github, stackoverflow, Google+ etc. Second of all, >> they are all clunky at best. Usability does matter to people. Finally, >> there are a lot new resources available out there and we are not tapping >> into it as best as we can. We should be using Travis and Jenkins in >> addition to CDash and CDash @ Home for example. >> >> So I don't think that this conversation is overkill. These discussions >> have a natural tendency to go on forever, I agree. So let's try to keep to >> the point and make some decisions soon. >> >> Best, >> -berk >> >> >> >> >> >> >> On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen >> wrote: >> >>> BTW the new gerrit UI is a bit prettier: >>> https://android-review.googlesource.com/#/q/status:open >>> >>> I'm a little concerned that we spend too much time on process and not >>> enough time on improving VTK. But, I'll go with the consensus of the >>> people who still work for a living. If the new process is too >>> difficult for an old guy like me, I'll just spend my extra time with >>> ITK. >>> >>> Bill >>> >>> >>> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride >>> wrote: >>> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said: >>> > >>> >>A fantasy feature for me would be that the system injects a step >>> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5 >>> >>reviewers for you based on reviewers "signing up" for reviewing certain >>> >>modules, or perhaps based on recent-ish commits in the same files... >>> > >>> > That would be a great addition. I often don't know who to add as a >>> reviewer, and I've been tinkering with VTK for years. Imagine a newbie! A >>> person can use 'git log' and 'git blame' to get some guesses, and that >>> could be automated. Of course, sometimes that results in suggesting >>> someone no longer involved with VTK or the infamous 'VTK developers', but >>> still it would help to automate it. >>> > >>> > 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 >>> > >>> > 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 bill.lorensen at gmail.com Tue Aug 26 16:09:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:09:13 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: I was addressing the first requirements list. Ease of use is subjective. On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: > I disagree. Gerrit does not support any of the "nice to have"s in a > straightforward way. Neither does vanilla Gerrit properly support "branch / > topic based workflow" in a straightforward way. It supports a changeset > based workflow and "branch / topic" based workflows have to be shoehorned > into it if a "branch / topic" has more than 1 changeset. Also to support > automated testing of branch tips, we would have to create custom scaffolding > since vanilla Gerrit has no such concept. > > Gerrit, with a little help from cdash @ home does a decent job of the > following: > > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > > It clearly doesn't do any of this: > > - Tight integration with issue (bug) tracking and release process > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > > In my opinion, it does a very poor job of these: > > - Branch / topic based workflow > - Ease of use > > The other requirements and nice-to-haves are independent of tools and can be > achieved using whatever tool. However, Mantis is also not the easiest tool > so replacing it is also a good idea. > > In my opinion, the biggest weaknesses of Github and Gitlab are: > > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > > They don't have a clear voting system and are based on more a general > discussion workflow. We would have to create some guidelines on how to > achieve these in those tools. For example, someone doing a pull request > would have to add a comment mentioning potential reviewers with the @name > syntax to "assign reviewers". The reviewers would have to use some > previously agreed upon language to approve a topic in the discussion. > Something like "Approved for merge". > > Github is far superior to Gerrit in these: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) - tight integration with > Travis and demonstrated integration with cdash @ home through custom hooks > - Automatic notification on change - much finer notification control > - Ability to comment on the code (Web GUI preferred) - go check it out if > you don't believe me > - Tight integration with issue (bug) tracking and release process > - Ease of use > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI - this is > impossible in Gerrit even for a single changeset > > Best, > -berk > > > > > > On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > wrote: >> >> +1 and Gerrit seems to support them all. >> >> >> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >> wrote: >> > Here is a summary that I came up with from the discussion so far. Does >> > this >> > look good? >> > >> > Requirements: >> > >> > - Branch / topic based workflow >> > - Automated testing before merge (required to pass) >> > - Assign reviewers to topic >> > - Review / approval before merge (required to pass) >> > - Ability to go back to discussion leading to merge (audit trail) >> > - Automatic notification on change >> > - Ability to comment on the code (Web GUI preferred) >> > - All reported bugs should be assessed and assigned >> > >> > Nice to have: >> > >> > - Tight integration with issue (bug) tracking and release process >> > - Stakeholders for particular pieces identified / in the loop / easy or >> > automatic assignment of >> > reviewers >> > - Ease of use >> > - Incentive for reviewers (goal being encouraging more reviews) >> > - Integration with Wiki >> > - Easy documentation / Markdown /rST support >> > - Easy way to generate single view of all changes in the Web GUI >> > - Lightweight proposal process for large changes >> > - Way to track performance regression >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > -- Unpaid intern in BillsBasement at noware dot com From aashish.chaudhary at kitware.com Tue Aug 26 16:09:09 2014 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 26 Aug 2014 16:09:09 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: > I disagree. Gerrit does not support any of the "nice to have"s in a > straightforward way. Neither does vanilla Gerrit properly support "branch > / topic based workflow" in a straightforward way. It supports a changeset > based workflow and "branch / topic" based workflows have to be shoehorned > into it if a "branch / topic" has more than 1 changeset. Also to support > automated testing of branch tips, we would have to create custom > scaffolding since vanilla Gerrit has no such concept. > > Gerrit, with a little help from cdash @ home does a decent job of the > following: > > - Automated testing before merge (required to pass) > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > - Automatic notification on change > - Ability to comment on the code (Web GUI preferred) > > It clearly doesn't do any of this: > > - Tight integration with issue (bug) tracking and release process > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI > > In my opinion, it does a very poor job of these: > > - Branch / topic based workflow > - Ease of use > > The other requirements and nice-to-haves are independent of tools and can > be achieved using whatever tool. However, Mantis is also not the easiest > tool so replacing it is also a good idea. > > In my opinion, the biggest weaknesses of Github and Gitlab are: > > - Assign reviewers to topic > - Review / approval before merge (required to pass) > - Ability to go back to discussion leading to merge (audit trail) > > They don't have a clear voting system and are based on more a general > discussion workflow. We would have to create some guidelines on how to > achieve these in those tools. For example, someone doing a pull request > would have to add a comment mentioning potential reviewers with the @name > syntax to "assign reviewers". The reviewers would have to use some > previously agreed upon language to approve a topic in the discussion. > Something like "Approved for merge". > > Github is far superior to Gerrit in these: > > - Branch / topic based workflow > - Automated testing before merge (required to pass) - tight integration > with Travis and demonstrated integration with cdash @ home through custom > hooks > - Automatic notification on change - much finer notification control > - Ability to comment on the code (Web GUI preferred) - go check it out if > you don't believe me > - Tight integration with issue (bug) tracking and release process > - Ease of use > - Integration with Wiki > - Easy documentation / Markdown /rST support > - Easy way to generate single view of all changes in the Web GUI - this is > impossible in Gerrit even for a single changeset > > +1 for the nice assessment. I have a memory of similar thought from some other developers outside Kitware on this. Best, > -berk > > > > > > On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > wrote: > >> +1 and Gerrit seems to support them all. >> >> >> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >> wrote: >> > Here is a summary that I came up with from the discussion so far. Does >> this >> > look good? >> > >> > Requirements: >> > >> > - Branch / topic based workflow >> > - Automated testing before merge (required to pass) >> > - Assign reviewers to topic >> > - Review / approval before merge (required to pass) >> > - Ability to go back to discussion leading to merge (audit trail) >> > - Automatic notification on change >> > - Ability to comment on the code (Web GUI preferred) >> > - All reported bugs should be assessed and assigned >> > >> > Nice to have: >> > >> > - Tight integration with issue (bug) tracking and release process >> > - Stakeholders for particular pieces identified / in the loop / easy or >> > automatic assignment of >> > reviewers >> > - Ease of use >> > - Incentive for reviewers (goal being encouraging more reviews) >> > - Integration with Wiki >> > - Easy documentation / Markdown /rST support >> > - Easy way to generate single view of all changes in the Web GUI >> > - Lightweight proposal process for large changes >> > - Way to track performance regression >> > >> >> >> >> -- >> 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 > > 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 bill.lorensen at gmail.com Tue Aug 26 16:25:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:25:13 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Berk, I think we need to reach out to potential developers. Especially those outside of Kitware(and their paying customers) and the long term VTK developers outside Kitware. Those communities can adapt to anything. We need to focus on is how can we can attract new developers. In the past, new processes were adopted and adapted by Kitware, their customers and hard core VTK developers with very little input from the broader community of potential developers. ITK is going through the same issues but addressing the issues not through process change. They are looking at outreach and better documentation of the current process. Matt McCormick at Kitware has been leading this effort. I think there are lots of non-process improvements possible. But I don't have a silver bullet for attracting new developers. Perhaps VTK is too old school for today's developers. Stuck with an old architecture, old graphics architecture, old and complex languages. I honestly don't know what the root causes are. If we only include the old-timers in theses discussion then we will not attract a younger set of devleopers. Bill On Tue, Aug 26, 2014 at 4:09 PM, Bill Lorensen wrote: > I was addressing the first requirements list. Ease of use is subjective. > > On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci wrote: >> I disagree. Gerrit does not support any of the "nice to have"s in a >> straightforward way. Neither does vanilla Gerrit properly support "branch / >> topic based workflow" in a straightforward way. It supports a changeset >> based workflow and "branch / topic" based workflows have to be shoehorned >> into it if a "branch / topic" has more than 1 changeset. Also to support >> automated testing of branch tips, we would have to create custom scaffolding >> since vanilla Gerrit has no such concept. >> >> Gerrit, with a little help from cdash @ home does a decent job of the >> following: >> >> - Automated testing before merge (required to pass) >> - Assign reviewers to topic >> - Review / approval before merge (required to pass) >> - Ability to go back to discussion leading to merge (audit trail) >> - Automatic notification on change >> - Ability to comment on the code (Web GUI preferred) >> >> It clearly doesn't do any of this: >> >> - Tight integration with issue (bug) tracking and release process >> - Integration with Wiki >> - Easy documentation / Markdown /rST support >> - Easy way to generate single view of all changes in the Web GUI >> >> In my opinion, it does a very poor job of these: >> >> - Branch / topic based workflow >> - Ease of use >> >> The other requirements and nice-to-haves are independent of tools and can be >> achieved using whatever tool. However, Mantis is also not the easiest tool >> so replacing it is also a good idea. >> >> In my opinion, the biggest weaknesses of Github and Gitlab are: >> >> - Assign reviewers to topic >> - Review / approval before merge (required to pass) >> - Ability to go back to discussion leading to merge (audit trail) >> >> They don't have a clear voting system and are based on more a general >> discussion workflow. We would have to create some guidelines on how to >> achieve these in those tools. For example, someone doing a pull request >> would have to add a comment mentioning potential reviewers with the @name >> syntax to "assign reviewers". The reviewers would have to use some >> previously agreed upon language to approve a topic in the discussion. >> Something like "Approved for merge". >> >> Github is far superior to Gerrit in these: >> >> - Branch / topic based workflow >> - Automated testing before merge (required to pass) - tight integration with >> Travis and demonstrated integration with cdash @ home through custom hooks >> - Automatic notification on change - much finer notification control >> - Ability to comment on the code (Web GUI preferred) - go check it out if >> you don't believe me >> - Tight integration with issue (bug) tracking and release process >> - Ease of use >> - Integration with Wiki >> - Easy documentation / Markdown /rST support >> - Easy way to generate single view of all changes in the Web GUI - this is >> impossible in Gerrit even for a single changeset >> >> Best, >> -berk >> >> >> >> >> >> On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen >> wrote: >>> >>> +1 and Gerrit seems to support them all. >>> >>> >>> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci >>> wrote: >>> > Here is a summary that I came up with from the discussion so far. Does >>> > this >>> > look good? >>> > >>> > Requirements: >>> > >>> > - Branch / topic based workflow >>> > - Automated testing before merge (required to pass) >>> > - Assign reviewers to topic >>> > - Review / approval before merge (required to pass) >>> > - Ability to go back to discussion leading to merge (audit trail) >>> > - Automatic notification on change >>> > - Ability to comment on the code (Web GUI preferred) >>> > - All reported bugs should be assessed and assigned >>> > >>> > Nice to have: >>> > >>> > - Tight integration with issue (bug) tracking and release process >>> > - Stakeholders for particular pieces identified / in the loop / easy or >>> > automatic assignment of >>> > reviewers >>> > - Ease of use >>> > - Incentive for reviewers (goal being encouraging more reviews) >>> > - Integration with Wiki >>> > - Easy documentation / Markdown /rST support >>> > - Easy way to generate single view of all changes in the Web GUI >>> > - Lightweight proposal process for large changes >>> > - Way to track performance regression >>> > >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:32:06 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:32:06 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton Message-ID: Hi folks, I propose a hack-a-ton to reduce the number of open issues in the bug tracker. It is like a yard that hasn't been mowed and weeded the whole summer. I propose a full day hack-a-ton. We can host some folks here at Kitware and others can join through a Google Hangout. I propose one in September. What do you think? Interested parties please send me an e-mail off the list with your preferred dates. This will have to be the first in a series. There are a lot of issues to go over. Best, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Aug 26 16:35:36 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:35:36 -0400 Subject: [vtk-developers] Attracting next generation of developers Message-ID: Moved this discussion to a new thread. Berk, I think we need to reach out to potential developers. Especially those outside of Kitware(and their paying customers) and the long term VTK developers outside Kitware. Those communities can adapt to anything. We need to focus on is how can we can attract new developers. In the past, new processes were adopted and adapted by Kitware, their customers and hard core VTK developers with very little input from the broader community of potential developers. ITK is going through the same issues but addressing the issues not through process change. They are looking at outreach and better documentation of the current process. Matt McCormick at Kitware has been leading this effort. I think there are lots of non-process improvements possible. But I don't have a silver bullet for attracting new developers. Perhaps VTK is too old school for today's developers. Stuck with an old architecture, old graphics architecture, old and complex languages. I honestly don't know what the root causes are. If we only include the old-timers in theses discussion then we will not attract a younger set of devleopers. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 16:43:13 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:43:13 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: I will attend if possible. October is better for me, I will be away September 17-27. Mondays and Wednesdays are bad (golf). Sept 8,9,10 are bad. On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci wrote: > Hi folks, > > I propose a hack-a-ton to reduce the number of open issues in the bug > tracker. It is like a yard that hasn't been mowed and weeded the whole > summer. I propose a full day hack-a-ton. We can host some folks here at > Kitware and others can join through a Google Hangout. I propose one in > September. What do you think? Interested parties please send me an e-mail > off the list with your preferred dates. > > This will have to be the first in a series. There are a lot of issues to go > over. > > Best, > -berk > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Aug 26 16:46:34 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 26 Aug 2014 16:46:34 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Hi Bill, +10 to more outreach and better documentation of, well, everything. The language is probably an issue also. Let alone the C++ 11 issue, Python, Javascript, Java etc. are definitely taking away some developers. What I am most interested in is making some of the large group of users out there into VTK developers. This is something we have never done well. Even when we had bunch more users & developers. I think that this is an accessibility thing. Being more open to contributions. Doing more outreach. Doing more things like Google Summer of Code. Doing more hack-a-tons. Other ideas? Modernization is certainly part of it. Of course modernization while maintaining the right level of usability - not something ITK has done exceedingly well I have to say. We are making decent progress in this area. Where we lack most often is communicating all of the work going on. To me some of this comes back to workflow and tools by the way. Workflow and tools make communication and outreach easier or harder. I'll leave that part of the discussion to the other thread. What do other people think? What are people willing to do more of? Best, -berk On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci wrote: > Moved this discussion to a new thread. > > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Aug 26 16:56:03 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 26 Aug 2014 16:56:03 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Berk, I agree that users of VTK are untapped as potential devleopers. Perhaps a short, focused outreach email to the VTK users list is in order. Bill On Tue, Aug 26, 2014 at 4:46 PM, Berk Geveci wrote: > Hi Bill, > > +10 to more outreach and better documentation of, well, everything. > > The language is probably an issue also. Let alone the C++ 11 issue, Python, > Javascript, Java etc. are definitely taking away some developers. > > What I am most interested in is making some of the large group of users out > there into VTK developers. This is something we have never done well. Even > when we had bunch more users & developers. I think that this is an > accessibility thing. Being more open to contributions. Doing more outreach. > Doing more things like Google Summer of Code. Doing more hack-a-tons. Other > ideas? > > Modernization is certainly part of it. Of course modernization while > maintaining the right level of usability - not something ITK has done > exceedingly well I have to say. We are making decent progress in this area. > Where we lack most often is communicating all of the work going on. > > To me some of this comes back to workflow and tools by the way. Workflow and > tools make communication and outreach easier or harder. I'll leave that part > of the discussion to the other thread. > > What do other people think? What are people willing to do more of? > > Best, > -berk > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: >> >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> > -- Unpaid intern in BillsBasement at noware dot com From will.schroeder at kitware.com Tue Aug 26 20:51:41 2014 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 26 Aug 2014 20:51:41 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Good stuff. Here are some random thoughts (besides some of the great stuff that's been mentioned before): + Provide potential community members an exciting purpose and/or a challenge. (See a list of crazy suggestions below.) I.e., paint a vision and get people excited due to social impact or technical challenge. + Define ways to contribute beyond just technical (i.e., lay out clear contribution paths), and recognize the community for these contributions. + Create "conferences" with invited speakers that get VTK developers and even application developers mixing together. Hold these at cool places with fun speakers and activities. The conferences could even have fun hackathon competitions addressing particular challenges / data. + Orgs like Kitware could invest some $ into awards, challenges, internships, etc. that are VTK-centric. + Here are crazy ideas for developing purposes/challenges: These need to capture the imagination and get people's creative juices flowing. These mini projects might be as simple as a single class/algorithm, or a complex as a subsystem. Maybe even consider something akin to ITK Applications which are satellite projects to leverage VTK infrastructure to do cool stuff. Lay out the challenges and recruit volunteers...if they are exciting enough it might attract talent and enthusiasm. -- Team with a data producer/application domain (like digital pathology, dermatolgy, environmental studies, microscopy, weather, sensor systems, etc.) and put together simple VTK-based tools for visualizing their data. These data could be associated with non-profits and/or research and represent significant social challenges. (I.e., help build a data-driven community with VTK playing a key role). -- Pick a technical challenge, like visualizing connectomics data, and with the help of the community use VTK as the core engine to build a simple application. The application might even be written in newer languages/environments (e.g., client-side). Other challenges might include mobile apps, etc. There's lots more but this is already long and crazy enough :-) W -- On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci wrote: > Moved this discussion to a new thread. > > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- 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 matt.mccormick at kitware.com Tue Aug 26 22:05:35 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 26 Aug 2014 22:05:35 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: +10 to the great comments by Bill, Berk, and Will. A few more thoughts to throw in the bucket: Another major factor to consider when attracting new developers is the cultivation of a sense of invested ownership. In connection with the review thread, it means that it is very important that reviews are encouraged from the community and that they are acknowledged. We do a good job of keeping track of Git patch authorship information -- we need to remember to keep track and promote review statistics, like in the visualization here [1] [2]. I disagree with the 'ITK is less usable' comment, not just because I am an ITK zealot ;-P. I think ITK is inherently as usable as VTK. It has a good software quality dashboard, like VTK, and the architecture and API, although orientated towards analysis instead of visualization, is at least modestly good like VTK. However, a person-oriented perception and experience of usability is more important than inherent, objective usability anyway. This subjective usability is highly influenced by an individual's background knowledge and the ability to acquire necessary knowledge. One strategy is to build bridges to familiar knowledge and provide documentation and training for the knowledge that is required. ITK now has a different API called SimpleITK [3], which is a better introduction for those unfamiliar with templates. Since the path to scientific programming most often involves coming from Python before C++, progress is being made to improve ITK wrapping. SimpleITK has great wrapping for Python and also other languages. The ITK Software Guide [4] is being updated, starting with updates and improvements on how to obtain and build the software. A new section was added recently on how to contribute. The excellent Wiki and Sphinx examples are also promoted and released with the code. Links are being added in the doxygen documentation to the book and example content. New code is required during review to have class and method documentation before merging [5]. These are examples of concrete steps that can be taken, but they could be improved, and there are other steps that could be taken. Another outstanding example that comes to mind is Berk's VTK NumPy interface blog posts [6], that both educate and bridge knowledge and technologies. I came across these customer reviews [1] on Amazon, and they have weighed on my mind. As a proud VTK and ITK community member, and as someone that has put sweat into a software book, they sting. But, they also inform the way to attract new developers and keep the ecosystem strong: provide basic, comprehensive documentation and create a fun, welcoming, merit-based community that has a big impact. Thanks for the long read, Matt [1] http://opensource.com/life/14/5/best-code-review-open-source-projects [2] http://thewtex.github.io/PropertiesOfCodeReviewSocialStructures/figures/itk_graph.html [3] http://simpleitk.org [4] http://itk.org/ITK/resources/software.html [5] http://review.source.kitware.com/#/c/11718/ [6] http://www.kitware.com/blog/home/post/723 [5] http://www.amazon.com/VTK-Users-Guide-Kitware/dp/1930934238/ref=sr_1_1?ie=UTF8&qid=1409085313&sr=8-1&keywords=vtk On Tue, Aug 26, 2014 at 8:51 PM, Will Schroeder wrote: > Good stuff. Here are some random thoughts (besides some of the great stuff > that's been mentioned before): > > + Provide potential community members an exciting purpose and/or a > challenge. (See a list of crazy suggestions below.) I.e., paint a vision and > get people excited due to social impact or technical challenge. > > + Define ways to contribute beyond just technical (i.e., lay out clear > contribution paths), and recognize the community for these contributions. > > + Create "conferences" with invited speakers that get VTK developers and > even application developers mixing together. Hold these at cool places with > fun speakers and activities. The conferences could even have fun hackathon > competitions addressing particular challenges / data. > > + Orgs like Kitware could invest some $ into awards, challenges, > internships, etc. that are VTK-centric. > > + Here are crazy ideas for developing purposes/challenges: These need to > capture the imagination and get people's creative juices flowing. These mini > projects might be as simple as a single class/algorithm, or a complex as a > subsystem. Maybe even consider something akin to ITK Applications which are > satellite projects to leverage VTK infrastructure to do cool stuff. Lay out > the challenges and recruit volunteers...if they are exciting enough it might > attract talent and enthusiasm. > > -- Team with a data producer/application domain (like digital pathology, > dermatolgy, environmental studies, microscopy, weather, sensor systems, > etc.) and put together simple VTK-based tools for visualizing their data. > These data could be associated with non-profits and/or research and > represent significant social challenges. (I.e., help build a data-driven > community with VTK playing a key role). > > -- Pick a technical challenge, like visualizing connectomics data, and with > the help of the community use VTK as the core engine to build a simple > application. The application might even be written in newer > languages/environments (e.g., client-side). Other challenges might include > mobile apps, etc. > > There's lots more but this is already long and crazy enough :-) > W > > > -- > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: >> >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > 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 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From biddisco at cscs.ch Wed Aug 27 03:16:43 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 07:16:43 +0000 Subject: [vtk-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR Message-ID: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Recompiling my Paraview plugins against the latest version, I find that many of the vtk::Keys I use frequently are gone. In order to handle my dynamic load balancing, I use the extent translators (particularly my own custom ones) continuously. Is there a replacement for this? 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 will.schroeder at kitware.com Wed Aug 27 07:25:19 2014 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 27 Aug 2014 07:25:19 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: A few more random thoughts: + Documentation: If we wanted to be really ambitious we would rewrite the VTK Textbook and User's Guide. Whatever we do, I'd like to see at least one "book" that is designed for interactivity from the ground up. An active publication that supports interactive book inserts where you can change view, parameters, etc. + Some of the most widely reused bits of VTK are "data" used to test or build examples. I've seen the cow, blade, combustor, etc. in technical papers, etc. We could build on this by gathering even more data and creating software/mini-apps around it. Even creating a series of reference benchmarks, etc. W On Tue, Aug 26, 2014 at 8:51 PM, Will Schroeder wrote: > Good stuff. Here are some random thoughts (besides some of the great stuff > that's been mentioned before): > > + Provide potential community members an exciting purpose and/or a > challenge. (See a list of crazy suggestions below.) I.e., paint a vision > and get people excited due to social impact or technical challenge. > > + Define ways to contribute beyond just technical (i.e., lay out clear > contribution paths), and recognize the community for these contributions. > > + Create "conferences" with invited speakers that get VTK developers and > even application developers mixing together. Hold these at cool places with > fun speakers and activities. The conferences could even have fun hackathon > competitions addressing particular challenges / data. > > + Orgs like Kitware could invest some $ into awards, challenges, > internships, etc. that are VTK-centric. > > + Here are crazy ideas for developing purposes/challenges: These need to > capture the imagination and get people's creative juices flowing. These > mini projects might be as simple as a single class/algorithm, or a complex > as a subsystem. Maybe even consider something akin to ITK Applications > which are satellite projects to leverage VTK infrastructure to do cool > stuff. Lay out the challenges and recruit volunteers...if they are exciting > enough it might attract talent and enthusiasm. > > -- Team with a data producer/application domain (like digital pathology, > dermatolgy, environmental studies, microscopy, weather, sensor systems, > etc.) and put together simple VTK-based tools for visualizing their data. > These data could be associated with non-profits and/or research and > represent significant social challenges. (I.e., help build a data-driven > community with VTK playing a key role). > > -- Pick a technical challenge, like visualizing connectomics data, and > with the help of the community use VTK as the core engine to build a simple > application. The application might even be written in newer > languages/environments (e.g., client-side). Other challenges might include > mobile apps, etc. > > There's lots more but this is already long and crazy enough :-) > W > > > -- > > > On Tue, Aug 26, 2014 at 4:35 PM, Berk Geveci > wrote: > >> Moved this discussion to a new thread. >> >> Berk, >> >> I think we need to reach out to potential developers. Especially those >> outside of Kitware(and their paying customers) and the long term VTK >> developers outside Kitware. Those communities can adapt to anything. >> We need to focus on is how can we can attract new developers. In the >> past, new processes were adopted and adapted by Kitware, their >> customers and hard core VTK developers with very little input from the >> broader community of potential developers. >> >> ITK is going through the same issues but addressing the issues not >> through process change. They are looking at outreach and better >> documentation of the current process. Matt McCormick at Kitware has >> been leading this effort. >> >> I think there are lots of non-process improvements possible. But I >> don't have a silver bullet for attracting new developers. Perhaps VTK >> is too old school for today's developers. Stuck with an old >> architecture, old graphics architecture, old and complex languages. I >> honestly don't know what the root causes are. If we only include the >> old-timers in theses discussion then we will not attract a younger set >> of devleopers. >> >> Bill >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > 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 berk.geveci at kitware.com Wed Aug 27 07:36:05 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 07:36:05 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Message-ID: Hi John, Check out: http://www.vtk.org/Wiki/VTK/Parallel_Pipeline Overall, load balancing should be much easier now. The reader can make arbitrary partitioning decisions but can still get requests from downstream about partitioning. Two main strategies: - Downstream send extent + piece requests, reader does its own partitioning based on these two - Downstream send specific extent requests to each rank (and no piece) The first one is appropriate to ParaView. This is much more robust and works through extract vois with subsampling etc. Something that never worked well in parallel. -berk On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. wrote: > Recompiling my Paraview plugins against the latest version, I find that > many of the vtk::Keys I use frequently are gone. > > > > In order to handle my dynamic load balancing, I use the extent translators > (particularly my own custom ones) continuously. > > > > Is there a replacement for this? > > > > 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 > > > > _______________________________________________ > Paraview-developers mailing list > Paraview-developers at paraview.org > http://public.kitware.com/mailman/listinfo/paraview-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Aug 27 07:46:53 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 11:46:53 +0000 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Berk, OK. I see how the piece requests change, but I was using the extent translator to pass bounds information and (more importantly) a PKdTree (from Zoltan) downstream to the compositing engine to stop it from instantiating the D3 filter and performing a redundant and slow repartition when I enable transparency. My Zoltan partitioner used to add an extent translator (also containgin the KdTree) to the information in the pipeline, which the compositing code could detect and act appropriately (with some minor tweaks). Has the compositing code been enhanced in any way to make use of partitioning information that I can piggy-back for my needs? JB From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: 27 August 2014 13:36 To: Biddiscombe, John A. Cc: vtk-developers at vtk.org; paraview-developers at paraview.org Subject: Re: [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR Hi John, Check out: http://www.vtk.org/Wiki/VTK/Parallel_Pipeline Overall, load balancing should be much easier now. The reader can make arbitrary partitioning decisions but can still get requests from downstream about partitioning. Two main strategies: - Downstream send extent + piece requests, reader does its own partitioning based on these two - Downstream send specific extent requests to each rank (and no piece) The first one is appropriate to ParaView. This is much more robust and works through extract vois with subsampling etc. Something that never worked well in parallel. -berk On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. > wrote: Recompiling my Paraview plugins against the latest version, I find that many of the vtk::Keys I use frequently are gone. In order to handle my dynamic load balancing, I use the extent translators (particularly my own custom ones) continuously. Is there a replacement for this? 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 _______________________________________________ Paraview-developers mailing list Paraview-developers at paraview.org http://public.kitware.com/mailman/listinfo/paraview-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Aug 27 07:57:52 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 27 Aug 2014 11:57:52 +0000 Subject: [vtk-developers] Driving away your existing developers Message-ID: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> I deliberately put this into a different thread from the attracting new developers conversation. If I were kitware, I'd be concerned that developers like myself - who kitware couldn't care less about - are unable to contribute to the project, and as we leave, the next generation of interns and students are not being encouraged to join. Why? Because tools like the gerrit review system have made it so painful to get patches accepted that it is easier to simply maintain our own branches in private repos and not try to get them into master. Why? Because kitware has become a vtk/paraview dictator and pushes all its own patches and restructures the libraries and code whenever and however it wants. Those of us outside kitware who are not paying customers and who do not have time to chase down reviewers can't get anything in. I do not object to Kitware being a dictator, after all I can fork the project and do anything I want with it too, but making it so hard for anyone else to get in is hurting the project, and since our patches need to be maintained against a changing master where our branches get broken often, it gets harder and harder with time to get features accepted. Last year my intern and I created a large patch/branch with significant new features (2D transfer functions) which just sits in gerrit and will never make it into a release. In the old days, I'd have committed it, watched the dashboards, created tests and made sure it smoothly transitioned into a release (and others would have chipped in with fixes when something on the dashboard broke). I don't have the time to check it still builds against the changing master branches and I know no one else will either. Having to manage gerrit branches/reviews for separate VTK/ParaView patches is hard work and most of us don't have the time to do it (our job is actually not to maintain vtk/paraview/etc). We created a video and posted it with public calls for reviewers on the lists, but did we get any response? No. If we can't get reviewers from the general public, then we can't contribute. End of story. VTK http://review.source.kitware.com/#/t/3736/ PV http://review.source.kitware.com/#/t/3737/ 9 months. No reviews. Another sad thing is that although I have other nice plugins for paraview which provide useful features others could benefit from, they will never get into the main repo, Kitware will eventually create their own versions of them (c.f zoltan/metis partitoners), thus duplicating the work - and at the same time making our stuff redundant. Normally, I'd accept that I'm just a whiner and tell me to shut up. But I/We really made an effort to get help with the transfer function stuff and the evidence is that nobody cares - so my whining is justified. Kitware does do a great job of moving the project forward - it's a shame that outsiders can't. 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 rroemer at gmail.com Wed Aug 27 08:37:01 2014 From: rroemer at gmail.com (=?UTF-8?Q?Ronald_R=C3=B6mer?=) Date: Wed, 27 Aug 2014 14:37:01 +0200 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: You are absolutely right, in most of your points. None if my commits were previewed by any native kitware developers. Its a pain to find the right previewers and after that none of them will do that job. So it is very hard for a new developer from outside the organization to get the right attention. This is frustrating... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Aug 27 08:54:26 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 27 Aug 2014 08:54:26 -0400 (EDT) Subject: [vtk-developers] Driving away your existing developers Message-ID: <8D1900D2AEFF48E-9F4-33CCB@webmail-vm086.sysops.aol.com> > If I were kitware, I?d be concerned that developers like myself - who > kitware couldn?t care less about - are unable to contribute to the > project, and as we leave, the next generation of interns and students > are not being encouraged to join. > ... > Normally, I?d accept that I?m just a whiner and tell me to shut up. > But I/We really made an effort to get help with the transfer function > stuff and the evidence is that nobody cares - so my whining is > justified. > ... > Kitware does do a great job of moving the project forward - it?s a > shame that outsiders can?t. This is a "hard to hear," but very valuable perspective from a long-time contributor to VTK and ParaView. Thanks, John, for expressing your opinion publicly, and clearly. Another way to phrase part of this discussion might be : "What would happen to these projects if Kitware abandoned them? How would the communities then re-organize...?" I've tried to stay active in CMake, VTK and ITK since leaving Kitware about 20 months ago, but it's been difficult to stay on top of it all. As John points out, for folks outside of Kitware, contributing is more of a "part time" endeavor that we have to squeeze in when we can. I'll continue to do so, because we use CMake, VTK and ITK to build our software, and I like to give back at least a little. John's topic in VTK is only one out of *126* open topics awaiting approval (or other dispensation) in gerrit, the oldest dating all the way back to September *2012*, a full two years ago. http://review.source.kitware.com/#/q/entity:topic%20status:open%20project:VTK,n,z In the other thread, about desired "workflow" and "tools," I expressed the desire to see reviewers assigned automatically when topics are submitted. That would help, but not totally solve the problem of an accumulating backlog of topics. Part of our workflow should be looking at the oldest topics in the queue, and deciding to abandon them at a certain point. After all, how many of the topics from more than 3 months ago would still merge successfully today even if approved...? An old topic / changeset with no reviewers should be a red flag that something's lacking in "the process." Unanswered emails on the list, unacknowledged bugs in the bug tracker, and unreviewed topics/changesets in gerrit are all issues that ought to be addressed to prevent driving existing people away and to help new contributors feel welcomed on a project. David C. From david.gobbi at gmail.com Wed Aug 27 09:13:19 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 07:13:19 -0600 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: The most important thing is to engage the community. Developers will be very forgiving about the process as long as you keep them engaged. Community engagement requires: - Responsive communication. You don't need to always have the answer, you just need to not be silent. - Dedication. Share your dreams and show that you care about the future. Help your employees to do the same. - Transparency. Lay out the roadmap for all to see. Summarize important development meetings on the wiki. You got this NIH grant, so far I see OpenGL2 and community outreach as aims, but for the most part I'm in the dark about your plans. When developers are kept in the dark, they feel like they're being shut out. There are several potential pools of developers: 1) VTK developers that currently hoard their code instead of contributing it back to VTK. This is a huge pool of capable developers. As John indicated in his email from this morning, process is important but the key is simple: when these people want to contribute, don't flat-out ignore them! 2) Companies for whom VTK is a core tool, and who therefore have a stake in its development. Really, these are the same as (1) except that they often have more resources. 3) Big grants and collaborations, where large chunks of development is done outside of Kitware. These undoubtedly help to increase the pool of developers, so a the question is, how to keep those developers engaged and ensure that good results are fed back into VTK. 4) Young hot-shots who see VTK as just the thing they need for their new project. For them, having a "Cool and Hip" VTK is important, but the three bullet points at the top of this email are much, much more important. I've got tons more that I could ramble on about, but it's time for breakfast (it's still 7am here in western Canada). - David From berk.geveci at kitware.com Wed Aug 27 09:10:46 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 09:10:46 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: You are both absolutely right. The review process is broken when it comes to accepting patches from the community. It is broken in 3 ways: 1. As Kitware, we haven't put the right attention to reviewing contributed code from top down (i.e. me and other managers using project resources and asking developers to review contributed work). Even when we have specific projects under which this can be done, we favor developing new code to reviewing contributions. 2. As individual contributors to VTK and ParaView, many of the Kitware developers are focused on their primary goals. We haven't built the open source community spirit as well as we can. Part of this needs to be done by the larger community with encouragement by senior folks (not just ones at Kitware). 3. As others pointed out, there is not enough emphasis and encouragement in reviewing code by the larger community. My code would languish in Gerrit if I didn't have the ability to walk to someone next door and ask them to review it please. David Gobbi and others had suggestions on how to encourage the larger community to be more involved in reviewing. My opinion is that this all boils down to making people feel ownership for VTK rather than seeing it as a tool that needs to be patched as necessary for other work or some project goal (deliver x,y and z and you are done). This is not something I can easily force people to do nor is it a top down thing. I am doing my best by encouraging more community engagement, removing barriers from tools and setting an example by contributing in various ways. I'd like to hear suggestions on how to achieve this and what I can do towards this. One idea: more community hack-a-tons. I just sent out a suggestion for addressing issues in the bug tracker. Why not have another one for reviewing code? One final note. Everyone please keep in mind that while there are quite a lot of contributors to VTK, certain parts of it are developed by only a few people. Core pipeline: I am it at this point. Rendering: by next year, it will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at Kitware does anything with imaging filters. We update them when we make changes to the pipeline or data model but that's it. So some of those are maintained and developed by others or they are some orphaned. This can only be addressed by either encouraging new (or existing) developers to take ownership or by removing those components all together. My 2 cents. -berk On Wed, Aug 27, 2014 at 8:37 AM, Ronald R?mer wrote: > You are absolutely right, in most of your points. None if my commits were > previewed by any native kitware developers. Its a pain to find the right > previewers and after that none of them will do that job. So it is very hard > for a new developer from outside the organization to get the right > attention. This is frustrating... > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.harris at kitware.com Wed Aug 27 09:32:40 2014 From: chris.harris at kitware.com (Chris Harris) Date: Wed, 27 Aug 2014 09:32:40 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <8D18EB506F9DB09-1E58-257B5@webmail-m289.sysops.aol.com> <20140825204530.1173865063@mail.rogue-research.com> <53FCBB58.5090405@gmail.com> Message-ID: Here is my two cents/pence, I apologize if I am rehashing already discussed topics, I am a little late to the party. In no particular order ? - The development process should be enforced and supported by the review tool rather than people and documents. No one wants to be the ?enforcer? and documents often go unread. - GitHub/GitLab PR workflow works well with projects that have a ?benevolent dictator? and relatively small teams, I?m not sure it scales so well when you have a larger number of people with merge access where more coordination is necessary. - As well as indicating approval, it is just as important to be able indicate that you don?t want something to be merged, for example a work in progress branch or you don?t agree with how something should be implemented. The likes of GitHub/GitLab tend to have an all or nothing approach here, if I have merge privileges I can merge any PR in the project and no one can stop me short of removing my privileges. - In my opinion no one should have push access to master, all merging should be done automatically. My understanding with GitHub/GitLab is if you can merge in the UI you can push to master. I have been in projects where developers have push to master by mistake, it happens. - Long running topic with lots of commits should be the exception rather than the rule. Topics that have a lot of commits are hard to review, in my opinion these could be treated differently as the usefulness of the review tool breaks down here. For VTK the mean number of changes in a topic: 1.88 and the median number of changes in a topic: 1. This to me indicates that topic branch support is a nice to have rather than a necessity. - I feel that as a part of the open source community we should be using open source tools where possible. So I would add being open source as a nice to have. - Finally I think supporting PR from GitHub is important, it's a familiar workflow for many developers. However, this doesn't mean that GitHub has to be our review tool. Integration is possible with other tools, for example Gerrit has a GitHub plugin. I have contributed to projects that use SVN through GitHub PRs :-) Regards, Chris On Tue, Aug 26, 2014 at 4:25 PM, Bill Lorensen wrote: > Berk, > > I think we need to reach out to potential developers. Especially those > outside of Kitware(and their paying customers) and the long term VTK > developers outside Kitware. Those communities can adapt to anything. > We need to focus on is how can we can attract new developers. In the > past, new processes were adopted and adapted by Kitware, their > customers and hard core VTK developers with very little input from the > broader community of potential developers. > > ITK is going through the same issues but addressing the issues not > through process change. They are looking at outreach and better > documentation of the current process. Matt McCormick at Kitware has > been leading this effort. > > I think there are lots of non-process improvements possible. But I > don't have a silver bullet for attracting new developers. Perhaps VTK > is too old school for today's developers. Stuck with an old > architecture, old graphics architecture, old and complex languages. I > honestly don't know what the root causes are. If we only include the > old-timers in theses discussion then we will not attract a younger set > of devleopers. > > Bill > > On Tue, Aug 26, 2014 at 4:09 PM, Bill Lorensen > wrote: > > I was addressing the first requirements list. Ease of use is subjective. > > > > On Tue, Aug 26, 2014 at 4:04 PM, Berk Geveci > wrote: > >> I disagree. Gerrit does not support any of the "nice to have"s in a > >> straightforward way. Neither does vanilla Gerrit properly support > "branch / > >> topic based workflow" in a straightforward way. It supports a changeset > >> based workflow and "branch / topic" based workflows have to be > shoehorned > >> into it if a "branch / topic" has more than 1 changeset. Also to support > >> automated testing of branch tips, we would have to create custom > scaffolding > >> since vanilla Gerrit has no such concept. > >> > >> Gerrit, with a little help from cdash @ home does a decent job of the > >> following: > >> > >> - Automated testing before merge (required to pass) > >> - Assign reviewers to topic > >> - Review / approval before merge (required to pass) > >> - Ability to go back to discussion leading to merge (audit trail) > >> - Automatic notification on change > >> - Ability to comment on the code (Web GUI preferred) > >> > >> It clearly doesn't do any of this: > >> > >> - Tight integration with issue (bug) tracking and release process > >> - Integration with Wiki > >> - Easy documentation / Markdown /rST support > >> - Easy way to generate single view of all changes in the Web GUI > >> > >> In my opinion, it does a very poor job of these: > >> > >> - Branch / topic based workflow > >> - Ease of use > >> > >> The other requirements and nice-to-haves are independent of tools and > can be > >> achieved using whatever tool. However, Mantis is also not the easiest > tool > >> so replacing it is also a good idea. > >> > >> In my opinion, the biggest weaknesses of Github and Gitlab are: > >> > >> - Assign reviewers to topic > >> - Review / approval before merge (required to pass) > >> - Ability to go back to discussion leading to merge (audit trail) > >> > >> They don't have a clear voting system and are based on more a general > >> discussion workflow. We would have to create some guidelines on how to > >> achieve these in those tools. For example, someone doing a pull request > >> would have to add a comment mentioning potential reviewers with the > @name > >> syntax to "assign reviewers". The reviewers would have to use some > >> previously agreed upon language to approve a topic in the discussion. > >> Something like "Approved for merge". > >> > >> Github is far superior to Gerrit in these: > >> > >> - Branch / topic based workflow > >> - Automated testing before merge (required to pass) - tight integration > with > >> Travis and demonstrated integration with cdash @ home through custom > hooks > >> - Automatic notification on change - much finer notification control > >> - Ability to comment on the code (Web GUI preferred) - go check it out > if > >> you don't believe me > >> - Tight integration with issue (bug) tracking and release process > >> - Ease of use > >> - Integration with Wiki > >> - Easy documentation / Markdown /rST support > >> - Easy way to generate single view of all changes in the Web GUI - this > is > >> impossible in Gerrit even for a single changeset > >> > >> Best, > >> -berk > >> > >> > >> > >> > >> > >> On Tue, Aug 26, 2014 at 3:43 PM, Bill Lorensen > > >> wrote: > >>> > >>> +1 and Gerrit seems to support them all. > >>> > >>> > >>> On Tue, Aug 26, 2014 at 3:32 PM, Berk Geveci > >>> wrote: > >>> > Here is a summary that I came up with from the discussion so far. > Does > >>> > this > >>> > look good? > >>> > > >>> > Requirements: > >>> > > >>> > - Branch / topic based workflow > >>> > - Automated testing before merge (required to pass) > >>> > - Assign reviewers to topic > >>> > - Review / approval before merge (required to pass) > >>> > - Ability to go back to discussion leading to merge (audit trail) > >>> > - Automatic notification on change > >>> > - Ability to comment on the code (Web GUI preferred) > >>> > - All reported bugs should be assessed and assigned > >>> > > >>> > Nice to have: > >>> > > >>> > - Tight integration with issue (bug) tracking and release process > >>> > - Stakeholders for particular pieces identified / in the loop / easy > or > >>> > automatic assignment of > >>> > reviewers > >>> > - Ease of use > >>> > - Incentive for reviewers (goal being encouraging more reviews) > >>> > - Integration with Wiki > >>> > - Easy documentation / Markdown /rST support > >>> > - Easy way to generate single view of all changes in the Web GUI > >>> > - Lightweight proposal process for large changes > >>> > - Way to track performance regression > >>> > > >>> > >>> > >>> > >>> -- > >>> Unpaid intern in BillsBasement at noware dot com > >> > >> > > > > > > > > -- > > Unpaid intern in BillsBasement at noware dot com > > > > -- > 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 > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wes.turner at kitware.com Wed Aug 27 10:02:21 2014 From: wes.turner at kitware.com (Wes Turner) Date: Wed, 27 Aug 2014 10:02:21 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 9:13 AM, David Gobbi wrote: > The most important thing is to engage the community. Developers will > be very forgiving about the process as long as you keep them engaged. > > Community engagement requires: > > - Responsive communication. You don't need to always have the answer, > you just need to not be silent. > > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. > > You got this NIH grant, so far I see OpenGL2 and community outreach > as aims, but for the most part I'm in the dark about your plans. When > developers are kept in the dark, they feel like they're being shut out. > > > There are several potential pools of developers: > > 1) VTK developers that currently hoard their code instead of > contributing it back to VTK. This is a huge pool of capable > developers. As John indicated in his email from this morning, > process is important but the key is simple: when these people > want to contribute, don't flat-out ignore them! > +1 Make contributing simple and be responsive. - Wes > 2) Companies for whom VTK is a core tool, and who therefore have a > stake in its development. Really, these are the same as (1) except > that they often have more resources. > > 3) Big grants and collaborations, where large chunks of development is > done outside of Kitware. These undoubtedly help to increase the pool > of developers, so a the question is, how to keep those developers > engaged and ensure that good results are fed back into VTK. > > 4) Young hot-shots who see VTK as just the thing they need for their > new project. For them, having a "Cool and Hip" VTK is important, but > the three bullet points at the top of this email are much, much more > important. > > I've got tons more that I could ramble on about, but it's time for > breakfast (it's still 7am here in western Canada). > > - David > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Wesley D. Turner, Ph.D. Kitware, Inc. Technical Leader 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4920 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Wed Aug 27 10:20:07 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 27 Aug 2014 10:20:07 -0400 Subject: [vtk-developers] VTK code review / testing / integration workflow In-Reply-To: References: <53FCBB58.5090405@gmail.com> Message-ID: <20140827142007.GA15572@megas.kitwarein.com> On Wed, Aug 27, 2014 at 09:32:40 -0400, Chris Harris wrote: > ? The development process should be enforced and supported by the review tool > rather than people and documents. No one wants to be the ??enforcer? and > documents often go unread. Agreed. > ? GitHub/GitLab PR workflow works well with projects that have a ?benevolent > dictator? and relatively small teams, I?m not sure it scales so well when > you have a larger number of people with merge access where more > coordination is necessary. The Rust repository juggles lots of incoming branches, but has a single bot do all of the merges based on comments from "blessed" contributors. > ? As well as indicating approval, it is just as important to be able indicate > that you don?t want something to be merged, for example a work in progress > branch or you don?t agree with how something should be implemented. The > likes of GitHub/GitLab tend to have an all or nothing approach here, if I > have merge privileges I can merge any PR in the project and no one can stop > me short of removing my privileges. I've usually put WIP in my topic names for works-in-progress that I'd like comments on before I dig a hole too deep on some feature. If maintainers pull it while it still has that tag then they're not really doing their job, IMO. If we had a mergebot, then it could just refuse anything with and active "WIP" tag (however it ends up being specified). > ? In my opinion no one should have push access to master, all merging should > be done automatically. My understanding with GitHub/GitLab is if you can > merge in the UI you can push to master. I have been in projects where > developers have push to master by mistake, it happens. +1 > ? Long running topic with lots of commits should be the exception rather than > the rule. Topics that have a lot of commits are hard to review, in my > opinion these could be treated differently as the usefulness of the review > tool breaks down here. For VTK the mean number of changes in a topic: 1.88 > and the median number of changes in a topic: 1. This to me indicates that > topic branch support is a nice to have rather than a necessity. Sure, the majority are single-commits, but there's no way that all branches belong in just one commit and that those branches are treated as second-rate citizens in review. I view it as an absolute necessity to support multi-commit branches gracefully. In fact, it is the larger branches that need *more* review tool support and ease-of-use than the small branches because they are already inherently hard to review. One thing I *really* want is a "full branch diff" view from the tool so that I can see the branch in its entirety. When I need to do this now, I pull from Gerrit, but it's a pain because getting the commits from there is unnecessarily complex (the ref names it uses aren't fetched by default). > ? I feel that as a part of the open source community we should be using open > source tools where possible. So I would add being open source as a nice to > have. +1 > ? Finally I think supporting PR from GitHub is important, it's a familiar > workflow for many developers. However, this doesn't mean that GitHub has to > be our review tool. Integration is possible with other tools, for example > Gerrit has a GitHub plugin. I have contributed to projects that use SVN > through GitHub PRs :-) A bot could pull PRs into whatever we end up using automatically with the web hooks Github provides. --Ben From david.gobbi at gmail.com Wed Aug 27 10:40:41 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 08:40:41 -0600 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 8:02 AM, Wes Turner wrote: > > +1 Make contributing simple and be responsive. I should add that it's absolutely fine to have a high rejection rate. If a submission is rejected, the developer might try again. If a submission is ignored, they won't! (Unless they're persistent SOBs like me.) - David From dlrdave at aol.com Wed Aug 27 10:47:17 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 27 Aug 2014 10:47:17 -0400 (EDT) Subject: [vtk-developers] Attracting next generation of developers Message-ID: <8D1901CEE92E699-FC0-31807@webmail-m218.sysops.aol.com> >> >> +1 Make contributing simple and be responsive. > I should add that it's absolutely fine to have a high rejection rate. > If a submission is rejected, the developer might try again. If a > submission is ignored, they won't! (Unless they're persistent SOBs > like me.) Definitely! People learn from rejection, it wakes them up and sometimes even inspires them, ... especially persistent SOBs. Think of it more as "suggesting refinement" than rejecting... :-) David C. From david.gobbi at gmail.com Wed Aug 27 12:00:21 2014 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 27 Aug 2014 10:00:21 -0600 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci wrote: > One final note. Everyone please keep in mind that while there are quite a > lot of contributors to VTK, certain parts of it are developed by only a few > people. Core pipeline: I am it at this point. Rendering: by next year, it > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at > Kitware does anything with imaging filters. We update them when we make > changes to the pipeline or data model but that's it. So some of those are > maintained and developed by others or they are some orphaned. This can only > be addressed by either encouraging new (or existing) developers to take > ownership or by removing those components all together. I have tons of plans for the VTK imaging classes, but unfortunately I have almost no resources so progress is slow. Some examples: 1) Improving both the API and the performance for multi-threading. Last year I worked with an intern to improve load sharing. Never had time to finish, because it wasn't the intern's main project. 2) Basic linear image registration in VTK. I've finished it and it's very robust (been using it for years), but refactoring so that it can be contributed to VTK is an evening/weekend project and hence is moving slowly. 3) Better image iterators. I have a nice image iterator that iterates over arbitrary shapes and also provides coordinate info while it iterates. I'd love to develop this further and contribute it, and I'd especially love to wrap it, but it's out in left field as far as my day job goes. 4) Better filters for going back and forth between image data and polydata. Lots of people use my vtkPolyDataToImageStencil filter, but it has faults and I know exactly how to fix them, but I'll have to wait until it comes up as a priority for one of my work projects. 5) Finally, a better overall structure for the imaging pipeline, focused on the basics: a) scalar operation "functors" that can be plugged into filters b) interpolators, which I've already committed c) good image "region" descriptors (like my vtkImageStencilData) d) connectivity & morphological operations, I've got lots of un-committed stuff e) a replacement for the lousy vtkImageMathematics filter Ideally I should write out a big roadmap (the items mentioned above is just a fraction of the total), but it would be depressing because so much of it feels like it's nothing more than a pipe dream. And, as Berk mentioned, there isn't anyone in Kitware for me to directly work with on this stuff. And all the other VTK imaging developers outside of Kitware are content to keep their work to themselves, without contributing back to the VTK core. Or at least, that's the way it looks from my vantage point. - David From pieper at isomics.com Wed Aug 27 17:03:55 2014 From: pieper at isomics.com (Steve Pieper) Date: Wed, 27 Aug 2014 17:03:55 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: I would love to see more of your excellent work, David, and I'd want to make use of it, but I'd argue that at least some of it, perhaps registration, may not belong in VTK itself. Speaking for myself from my experience in the slicer project, I can say that we end up putting a lot of our functionality in classes that don't belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of which adds functionality that is independent of our slicer application, but adds a layer of dependencies that nobody would want to see in VTK itself. On my wishlist for VTK would be a better way for new developers to contribute their work so that it's easily usable by others but doesn't have to pass the gauntlet of reviews and comments and be in VTK before it is easily usable by others. I'd like to see an experience more like npm for node, where anyone can publish a domain-specific set of code and other people can use it or not as they see fit. Node itself remains small and it rarely changes, but the ecosystem is quite vibrant. It allows a lot of diversity, but amazing interoperability and reusability. In slicer we have something similar now with the Extension Catalog, where developers can offer code (either pure VTK or things that work at the VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform nightly builds and test it on all platforms, this code is in reasonable shape for other people to draw from, either in slicer or elsewhere. Typically these extensions are in github repositories, so they have their own wikis, issue lists, pull requests, etc. We hope that slicer itself actually gets smaller over time and generally doesn't need to change very much or very often. I would love to see something similar in VTK proper. Right now VTK has a lot of modules that are quite domain specific, such as Chemistry and Geovis which I do not envision using myself. I would have preferred to see that code exist in a different repository where people who needed it would have the option of including it in their superbuild process. Others could safely ignore it. I would even argue that half (or more) of the current modules don't really belong in the 'actual' VTK and should be moved out. If there were a good place to put some of this kind of code it might also be a good spot for libraries like vtkITK and vtkTeem. In fact I would argue that if it weren't actually in VTK's repository, a project like vtkChemistry might attract more participants and have more features (but I can't prove that of course). So basically I'd say that VTK is currently too big and should get smaller, while the community is too small and should get bigger. -Steve On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi wrote: > On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci > wrote: > > > One final note. Everyone please keep in mind that while there are quite a > > lot of contributors to VTK, certain parts of it are developed by only a > few > > people. Core pipeline: I am it at this point. Rendering: by next year, it > > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis > team at > > Kitware does anything with imaging filters. We update them when we make > > changes to the pipeline or data model but that's it. So some of those are > > maintained and developed by others or they are some orphaned. This can > only > > be addressed by either encouraging new (or existing) developers to take > > ownership or by removing those components all together. > > I have tons of plans for the VTK imaging classes, but unfortunately I have > almost no resources so progress is slow. Some examples: > > 1) Improving both the API and the performance for multi-threading. > Last year I worked with an intern to improve load sharing. Never had > time to finish, because it wasn't the intern's main project. > > 2) Basic linear image registration in VTK. I've finished it and it's > very robust (been using it for years), but refactoring so that it can > be contributed to VTK is an evening/weekend project and hence is > moving slowly. > > 3) Better image iterators. I have a nice image iterator that iterates > over arbitrary shapes and also provides coordinate info while it > iterates. I'd love to develop this further and contribute it, and I'd > especially love to wrap it, but it's out in left field as far as my > day job goes. > > 4) Better filters for going back and forth between image data and > polydata. Lots of people use my vtkPolyDataToImageStencil filter, > but it has faults and I know exactly how to fix them, but I'll have to > wait until it comes up as a priority for one of my work projects. > > 5) Finally, a better overall structure for the imaging pipeline, > focused on the basics: > a) scalar operation "functors" that can be plugged into filters > b) interpolators, which I've already committed > c) good image "region" descriptors (like my vtkImageStencilData) > d) connectivity & morphological operations, I've got lots of un-committed > stuff > e) a replacement for the lousy vtkImageMathematics filter > > Ideally I should write out a big roadmap (the items mentioned above > is just a fraction of the total), but it would be depressing because so > much of it feels like it's nothing more than a pipe dream. > > And, as Berk mentioned, there isn't anyone in Kitware for me to > directly work with on this stuff. And all the other VTK imaging > developers outside of Kitware are content to keep their work to > themselves, without contributing back to the VTK core. Or at least, > that's the way it looks from my vantage point. > > - David > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Aug 27 18:03:06 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 27 Aug 2014 18:03:06 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Message-ID: Hi John, Good news. It is now much easier to propagate meta-data and requests in VTK now. (Don't give me a hard time about not communicating this. I am working on my issues). All you need is a subclass of a vtkInformationKey that overrides CopyDefaultInformation(), probably to copy itself. Look at vtkEnsembleSource and vtkInformationDataObjectMetaDataKey to see an example. In fact, if your kd tree is a vtkDataObject subclass, you can use that key class to define a custom key like vtkEnsembleSource. No more need for keys to copy silliness. There is also support for adding arbitrary request objects without changing executives. Look at vtkInformationIntegerRequestKey to see an example. You need a key subclass that overrides CopyDefaultInformation(), NeedToExecute(), StoreMetaData() for that. I will write a blog with details in the near future. Best, -berk On Wed, Aug 27, 2014 at 7:46 AM, Biddiscombe, John A. wrote: > Berk, > > > > OK. I see how the piece requests change, but I was using the extent > translator to pass bounds information and (more importantly) a PKdTree > (from Zoltan) downstream to the compositing engine to stop it from > instantiating the D3 filter and performing a redundant and slow repartition > when I enable transparency. My Zoltan partitioner used to add an extent > translator (also containgin the KdTree) to the information in the pipeline, > which the compositing code could detect and act appropriately (with some > minor tweaks). > > > > Has the compositing code been enhanced in any way to make use of > partitioning information that I can piggy-back for my needs? > > > > JB > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* 27 August 2014 13:36 > *To:* Biddiscombe, John A. > *Cc:* vtk-developers at vtk.org; paraview-developers at paraview.org > *Subject:* Re: [Paraview-developers] > vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR > > > > Hi John, > > > > Check out: > > > > http://www.vtk.org/Wiki/VTK/Parallel_Pipeline > > > > Overall, load balancing should be much easier now. The reader can make > arbitrary partitioning decisions but can still get requests from downstream > about partitioning. Two main strategies: > > > > - Downstream send extent + piece requests, reader does its own > partitioning based on these two > > - Downstream send specific extent requests to each rank (and no piece) > > > > The first one is appropriate to ParaView. > > > > This is much more robust and works through extract vois with subsampling > etc. Something that never worked well in parallel. > > > > -berk > > > > On Wed, Aug 27, 2014 at 3:16 AM, Biddiscombe, John A. > wrote: > > Recompiling my Paraview plugins against the latest version, I find that > many of the vtk::Keys I use frequently are gone. > > > > In order to handle my dynamic load balancing, I use the extent translators > (particularly my own custom ones) continuously. > > > > Is there a replacement for this? > > > > 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 > > > > > _______________________________________________ > Paraview-developers mailing list > Paraview-developers at paraview.org > http://public.kitware.com/mailman/listinfo/paraview-developers > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 Wed Aug 27 20:58:48 2014 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 27 Aug 2014 20:58:48 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: ITK's remote module mechanism is a great way to add domain specific modules. I agree with Steve that vtk proper should get smaller. On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: > I would love to see more of your excellent work, David, and I'd want to > make use of it, but I'd argue that at least some of it, perhaps > registration, may not belong in VTK itself. > > Speaking for myself from my experience in the slicer project, I can say > that we end up putting a lot of our functionality in classes that don't > belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of > which adds functionality that is independent of our slicer application, but > adds a layer of dependencies that nobody would want to see in VTK itself. > > On my wishlist for VTK would be a better way for new developers to > contribute their work so that it's easily usable by others but doesn't have > to pass the gauntlet of reviews and comments and be in VTK before it is > easily usable by others. I'd like to see an experience more like npm for > node, where anyone can publish a domain-specific set of code and other > people can use it or not as they see fit. Node itself remains small and it > rarely changes, but the ecosystem is quite vibrant. It allows a lot of > diversity, but amazing interoperability and reusability. > > In slicer we have something similar now with the Extension Catalog, where > developers can offer code (either pure VTK or things that work at the > VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform > nightly builds and test it on all platforms, this code is in reasonable > shape for other people to draw from, either in slicer or elsewhere. > Typically these extensions are in github repositories, so they have their > own wikis, issue lists, pull requests, etc. We hope that slicer itself > actually gets smaller over time and generally doesn't need to change very > much or very often. > > I would love to see something similar in VTK proper. Right now VTK has a > lot of modules that are quite domain specific, such as Chemistry and Geovis > which I do not envision using myself. I would have preferred to see that > code exist in a different repository where people who needed it would have > the option of including it in their superbuild process. Others could > safely ignore it. I would even argue that half (or more) of the current > modules don't really belong in the 'actual' VTK and should be moved out. > If there were a good place to put some of this kind of code it might also > be a good spot for libraries like vtkITK and vtkTeem. In fact I would > argue that if it weren't actually in VTK's repository, a project like > vtkChemistry might attract more participants and have more features (but I > can't prove that of course). > > So basically I'd say that VTK is currently too big and should get smaller, > while the community is too small and should get bigger. > > -Steve > > > On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi > wrote: > >> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >> wrote: >> >> > One final note. Everyone please keep in mind that while there are quite >> a >> > lot of contributors to VTK, certain parts of it are developed by only a >> few >> > people. Core pipeline: I am it at this point. Rendering: by next year, >> it >> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >> team at >> > Kitware does anything with imaging filters. We update them when we make >> > changes to the pipeline or data model but that's it. So some of those >> are >> > maintained and developed by others or they are some orphaned. This can >> only >> > be addressed by either encouraging new (or existing) developers to take >> > ownership or by removing those components all together. >> >> I have tons of plans for the VTK imaging classes, but unfortunately I have >> almost no resources so progress is slow. Some examples: >> >> 1) Improving both the API and the performance for multi-threading. >> Last year I worked with an intern to improve load sharing. Never had >> time to finish, because it wasn't the intern's main project. >> >> 2) Basic linear image registration in VTK. I've finished it and it's >> very robust (been using it for years), but refactoring so that it can >> be contributed to VTK is an evening/weekend project and hence is >> moving slowly. >> >> 3) Better image iterators. I have a nice image iterator that iterates >> over arbitrary shapes and also provides coordinate info while it >> iterates. I'd love to develop this further and contribute it, and I'd >> especially love to wrap it, but it's out in left field as far as my >> day job goes. >> >> 4) Better filters for going back and forth between image data and >> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >> but it has faults and I know exactly how to fix them, but I'll have to >> wait until it comes up as a priority for one of my work projects. >> >> 5) Finally, a better overall structure for the imaging pipeline, >> focused on the basics: >> a) scalar operation "functors" that can be plugged into filters >> b) interpolators, which I've already committed >> c) good image "region" descriptors (like my vtkImageStencilData) >> d) connectivity & morphological operations, I've got lots of >> un-committed stuff >> e) a replacement for the lousy vtkImageMathematics filter >> >> Ideally I should write out a big roadmap (the items mentioned above >> is just a fraction of the total), but it would be depressing because so >> much of it feels like it's nothing more than a pipe dream. >> >> And, as Berk mentioned, there isn't anyone in Kitware for me to >> directly work with on this stuff. And all the other VTK imaging >> developers outside of Kitware are content to keep their work to >> themselves, without contributing back to the VTK core. Or at least, >> that's the way it looks from my vantage point. >> >> - David >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > 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 Aug 28 10:10:42 2014 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Thu, 28 Aug 2014 14:10:42 +0000 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> Berk Thanks once more for the info. Question : The class I want to pass downstream is a vtkObject and not a vtkDataObject, so .. There are informationDataObject and InformationDataObjectMetaData keys, but there are not informationObject and InformationObjectMetaData keys, but since DataObject is a type of Object, would anything be adversely affected if I were to change them to InformationObject->InformationObjectMetaData and provide a GetObject and GetDataObject interface to return the type contained? Adding two new classes seems wasteful when they actually do the same thing internally. Do the informationDataObject and metadata key classes need to specialized as different from Object and ObjectMetaData? (other than just for naming purposes) ta JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Aug 28 10:16:49 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:16:49 -0400 Subject: [vtk-developers] [Paraview-developers] vtkStreamingDemandDrivenPipeline::EXTENT_TRANSLATOR In-Reply-To: <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> References: <50320452A334BD42A5EC72BAD214509916C0768B@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509916C0798E@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD214509918DC428E@MBX110.d.ethz.ch> Message-ID: I have no objection whatsoever to changing it to be a subclass of vtkInformationObjectBaseKey and renaming it as such. It should work but please run the ensemble source test to make sure. -berk On Thu, Aug 28, 2014 at 10:10 AM, Biddiscombe, John A. wrote: > Berk > > > > Thanks once more for the info. > > > > Question : > > > > The class I want to pass downstream is a vtkObject and not a > vtkDataObject, so .. > > > > There are > > informationDataObject and InformationDataObjectMetaData keys, but there > are not > > informationObject and InformationObjectMetaData keys, > > > > but since DataObject is a type of Object, would anything be adversely > affected if I were to change them to > > InformationObject->InformationObjectMetaData > > > > and provide a GetObject and GetDataObject interface to return the type > contained? Adding two new classes seems wasteful when they actually do the > same thing internally. > > > > Do the informationDataObject and metadata key classes need to specialized > as different from Object and ObjectMetaData? (other than just for naming > purposes) > > > > ta > > > > JB > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 28 10:18:22 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 28 Aug 2014 10:18:22 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: <20140828141822.216694143@mail.rogue-research.com> On Tue, 26 Aug 2014 16:43:13 -0400, Bill Lorensen said: >I will attend if possible. October is better for me, I will be away >September 17-27. Mondays and Wednesdays are bad (golf). Sept 8,9,10 >are bad. I will also attend if possible. Always fun to meet up in person. October also better for me. I'm leaving for vacation for the next two weeks tonight (BTW: email support at rogue if one of our buildbots needs kicking) and will be busy catching up the week I'm back. 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 berk.geveci at kitware.com Thu Aug 28 10:21:39 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:21:39 -0400 Subject: [vtk-developers] Proposal: Bug tracker hack-a-ton In-Reply-To: References: Message-ID: Several people indicated a preference for October. How about October 2nd? Best, -berk On Tue, Aug 26, 2014 at 4:32 PM, Berk Geveci wrote: > Hi folks, > > I propose a hack-a-ton to reduce the number of open issues in the bug > tracker. It is like a yard that hasn't been mowed and weeded the whole > summer. I propose a full day hack-a-ton. We can host some folks here at > Kitware and others can join through a Google Hangout. I propose one in > September. What do you think? Interested parties please send me an e-mail > off the list with your preferred dates. > > This will have to be the first in a series. There are a lot of issues to > go over. > > Best, > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Aug 28 10:44:58 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 10:44:58 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: > I agree with Steve that vtk proper should get smaller. I agree with the spirit of this. In fact, I get very exciting thinking about how this would work and how nice and useful the infrastructure would be. However, I don't think it is very feasible to use such a mechanism to pull out parts of current VTK. It is a maintenance issue. We have had years of experience of maintaining tightly coupled projects that are in separate repositories (VTK and ParaView). And it is not easy. It requires team dedicated to maintaining each separately, with separate dashboard architecture, git branches, code review processes etc. If we had, say, 10 small projects that tightly depended on VTK and was developed by roughly the same team, there would be a significant overhead to development and maintenance. What would the development workflow be to keep these in sync? Having the "remote" modules depend on a release version of VTK is not tightly coupled enough and would hamper development significantly. So we would have to manage some version dependency mechanism that would be at best hard. I can see making a handful of modules that hardly change external. Or some modules that change more regularly but depend less on changes to core features. Some of the IO modules with external dependencies, maybe VTK Web, some filtering module such as Matlab, R, Reebgraph etc. But is it really worth the trouble? It would shrink VTK slightly but would make testing, integration etc. harder for everyone. I would rather focus on implementing this for new projects / modules. Specially those that are developed in a way that's less coupled with VTK. Some Slicer code could be organized this way for example. Slicer depends on a release version of VTK and has its own testing infrastructure so it should be easy. Things like ITK-VTK adapters could probably be organized the same way. What would the mechanism for indicating version dependencies, whether a remote module is tested regularly and things like that? Best, -berk On Wed, Aug 27, 2014 at 8:58 PM, Bill Lorensen wrote: > ITK's remote module mechanism is a great way to add domain specific > modules. I agree with Steve that vtk proper should get smaller. > On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: > >> I would love to see more of your excellent work, David, and I'd want to >> make use of it, but I'd argue that at least some of it, perhaps >> registration, may not belong in VTK itself. >> >> Speaking for myself from my experience in the slicer project, I can say >> that we end up putting a lot of our functionality in classes that don't >> belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of >> which adds functionality that is independent of our slicer application, but >> adds a layer of dependencies that nobody would want to see in VTK itself. >> >> On my wishlist for VTK would be a better way for new developers to >> contribute their work so that it's easily usable by others but doesn't have >> to pass the gauntlet of reviews and comments and be in VTK before it is >> easily usable by others. I'd like to see an experience more like npm for >> node, where anyone can publish a domain-specific set of code and other >> people can use it or not as they see fit. Node itself remains small and it >> rarely changes, but the ecosystem is quite vibrant. It allows a lot of >> diversity, but amazing interoperability and reusability. >> >> In slicer we have something similar now with the Extension Catalog, where >> developers can offer code (either pure VTK or things that work at the >> VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform >> nightly builds and test it on all platforms, this code is in reasonable >> shape for other people to draw from, either in slicer or elsewhere. >> Typically these extensions are in github repositories, so they have their >> own wikis, issue lists, pull requests, etc. We hope that slicer itself >> actually gets smaller over time and generally doesn't need to change very >> much or very often. >> >> I would love to see something similar in VTK proper. Right now VTK has a >> lot of modules that are quite domain specific, such as Chemistry and Geovis >> which I do not envision using myself. I would have preferred to see that >> code exist in a different repository where people who needed it would have >> the option of including it in their superbuild process. Others could >> safely ignore it. I would even argue that half (or more) of the current >> modules don't really belong in the 'actual' VTK and should be moved out. >> If there were a good place to put some of this kind of code it might also >> be a good spot for libraries like vtkITK and vtkTeem. In fact I would >> argue that if it weren't actually in VTK's repository, a project like >> vtkChemistry might attract more participants and have more features (but I >> can't prove that of course). >> >> So basically I'd say that VTK is currently too big and should get >> smaller, while the community is too small and should get bigger. >> >> -Steve >> >> >> On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi >> wrote: >> >>> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >>> wrote: >>> >>> > One final note. Everyone please keep in mind that while there are >>> quite a >>> > lot of contributors to VTK, certain parts of it are developed by only >>> a few >>> > people. Core pipeline: I am it at this point. Rendering: by next year, >>> it >>> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >>> team at >>> > Kitware does anything with imaging filters. We update them when we make >>> > changes to the pipeline or data model but that's it. So some of those >>> are >>> > maintained and developed by others or they are some orphaned. This can >>> only >>> > be addressed by either encouraging new (or existing) developers to take >>> > ownership or by removing those components all together. >>> >>> I have tons of plans for the VTK imaging classes, but unfortunately I >>> have >>> almost no resources so progress is slow. Some examples: >>> >>> 1) Improving both the API and the performance for multi-threading. >>> Last year I worked with an intern to improve load sharing. Never had >>> time to finish, because it wasn't the intern's main project. >>> >>> 2) Basic linear image registration in VTK. I've finished it and it's >>> very robust (been using it for years), but refactoring so that it can >>> be contributed to VTK is an evening/weekend project and hence is >>> moving slowly. >>> >>> 3) Better image iterators. I have a nice image iterator that iterates >>> over arbitrary shapes and also provides coordinate info while it >>> iterates. I'd love to develop this further and contribute it, and I'd >>> especially love to wrap it, but it's out in left field as far as my >>> day job goes. >>> >>> 4) Better filters for going back and forth between image data and >>> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >>> but it has faults and I know exactly how to fix them, but I'll have to >>> wait until it comes up as a priority for one of my work projects. >>> >>> 5) Finally, a better overall structure for the imaging pipeline, >>> focused on the basics: >>> a) scalar operation "functors" that can be plugged into filters >>> b) interpolators, which I've already committed >>> c) good image "region" descriptors (like my vtkImageStencilData) >>> d) connectivity & morphological operations, I've got lots of >>> un-committed stuff >>> e) a replacement for the lousy vtkImageMathematics filter >>> >>> Ideally I should write out a big roadmap (the items mentioned above >>> is just a fraction of the total), but it would be depressing because so >>> much of it feels like it's nothing more than a pipe dream. >>> >>> And, as Berk mentioned, there isn't anyone in Kitware for me to >>> directly work with on this stuff. And all the other VTK imaging >>> developers outside of Kitware are content to keep their work to >>> themselves, without contributing back to the VTK core. Or at least, >>> that's the way it looks from my vantage point. >>> >>> - David >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> >>> >>> The information in this e-mail is intended only for the person to whom >>> it is >>> addressed. If you believe this e-mail was sent to you in error and the >>> e-mail >>> contains patient information, please contact the Partners Compliance >>> HelpLine at >>> http://www.partners.org/complianceline . If the e-mail was sent to you >>> in error >>> but does not contain patient information, please contact the sender and >>> properly >>> dispose of the e-mail. >>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 28 11:07:49 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 28 Aug 2014 11:07:49 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: <20140828150749.1061007759@mail.rogue-research.com> Hi all, Alas I haven't had the time with my impending vacation to add some thoughts, but I'll say broadly that I agree with what most of you are saying. One thing I don't think anyone has said, maybe because I'm the only one that thinks this way :), is that I find it hard to follow what changes are happening in VTK. Certainly reading the lists and kitware blog helps, but I think it would be cool to have 2 additional things: 1) a 'commits' email list, like other projects. Where you get an email for every merge into master. 2) a weekly summary like this: Which obviously would take time and effort on someone's part, but would be cool. :) You kitware guys probably chat at lunch about what others are doing, but from outside it's not always so clear. 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 pieper at isomics.com Thu Aug 28 11:17:51 2014 From: pieper at isomics.com (Steve Pieper) Date: Thu, 28 Aug 2014 11:17:51 -0400 Subject: [vtk-developers] Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: Hi Berk - This is a helpful discussion and I like that we are thinking through the implications before making any decisions. I also think we should look at development communities that work well, and try to learn from those examples. That's why I suggested node and npm as an ecosystem that seems to really work in my experience. There's lots of sophisticated code that works well together and people use it to create software that is of similar complexity to VTK and ParaView. There are well established testing and version control methodologies. The core is very small and stable, but there are packages for just about anything you can imagine. The community also attracts contributions from all the types David mentioned (companies, academics, and sharp independent developers). Do people have other community models that they think work well and would be worth studying? Or perhaps we could also learn from failed/failing communities, so as not to repeat their mistakes. -Steve On Thu, Aug 28, 2014 at 10:44 AM, Berk Geveci wrote: > > I agree with Steve that vtk proper should get smaller. > > I agree with the spirit of this. In fact, I get very exciting thinking > about how this would work and how nice and > useful the infrastructure would be. However, I don't think it is very > feasible to use such a mechanism to > pull out parts of current VTK. It is a maintenance issue. We have had > years of experience of maintaining > tightly coupled projects that are in separate repositories (VTK and > ParaView). And it is not easy. It requires > team dedicated to maintaining each separately, with separate dashboard > architecture, git branches, code > review processes etc. If we had, say, 10 small projects that tightly > depended on VTK and was developed > by roughly the same team, there would be a significant overhead to > development and maintenance. What > would the development workflow be to keep these in sync? Having the > "remote" modules depend on a release > version of VTK is not tightly coupled enough and would hamper development > significantly. So we would > have to manage some version dependency mechanism that would be at best > hard. > > I can see making a handful of modules that hardly change external. Or some > modules that change more > regularly but depend less on changes to core features. Some of the IO > modules with external dependencies, > maybe VTK Web, some filtering module such as Matlab, R, Reebgraph etc. But > is it really worth the trouble? > It would shrink VTK slightly but would make testing, integration etc. > harder for everyone. > > I would rather focus on implementing this for new projects / modules. > Specially those that are developed > in a way that's less coupled with VTK. Some Slicer code could be organized > this way for example. Slicer > depends on a release version of VTK and has its own testing infrastructure > so it should be easy. Things > like ITK-VTK adapters could probably be organized the same way. > > What would the mechanism for indicating version dependencies, whether a > remote module is tested > regularly and things like that? > > Best, > -berk > > > On Wed, Aug 27, 2014 at 8:58 PM, Bill Lorensen > wrote: > >> ITK's remote module mechanism is a great way to add domain specific >> modules. I agree with Steve that vtk proper should get smaller. >> On Aug 27, 2014 5:04 PM, "Steve Pieper" wrote: >> >>> I would love to see more of your excellent work, David, and I'd want to >>> make use of it, but I'd argue that at least some of it, perhaps >>> registration, may not belong in VTK itself. >>> >>> Speaking for myself from my experience in the slicer project, I can say >>> that we end up putting a lot of our functionality in classes that don't >>> belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of >>> which adds functionality that is independent of our slicer application, but >>> adds a layer of dependencies that nobody would want to see in VTK itself. >>> >>> On my wishlist for VTK would be a better way for new developers to >>> contribute their work so that it's easily usable by others but doesn't have >>> to pass the gauntlet of reviews and comments and be in VTK before it is >>> easily usable by others. I'd like to see an experience more like npm for >>> node, where anyone can publish a domain-specific set of code and other >>> people can use it or not as they see fit. Node itself remains small and it >>> rarely changes, but the ecosystem is quite vibrant. It allows a lot of >>> diversity, but amazing interoperability and reusability. >>> >>> In slicer we have something similar now with the Extension Catalog, >>> where developers can offer code (either pure VTK or things that work at the >>> VTK/ITK/Qt/Slicer level) that is optionally installed. Since we perform >>> nightly builds and test it on all platforms, this code is in reasonable >>> shape for other people to draw from, either in slicer or elsewhere. >>> Typically these extensions are in github repositories, so they have their >>> own wikis, issue lists, pull requests, etc. We hope that slicer itself >>> actually gets smaller over time and generally doesn't need to change very >>> much or very often. >>> >>> I would love to see something similar in VTK proper. Right now VTK has >>> a lot of modules that are quite domain specific, such as Chemistry and >>> Geovis which I do not envision using myself. I would have preferred to see >>> that code exist in a different repository where people who needed it would >>> have the option of including it in their superbuild process. Others could >>> safely ignore it. I would even argue that half (or more) of the current >>> modules don't really belong in the 'actual' VTK and should be moved out. >>> If there were a good place to put some of this kind of code it might also >>> be a good spot for libraries like vtkITK and vtkTeem. In fact I would >>> argue that if it weren't actually in VTK's repository, a project like >>> vtkChemistry might attract more participants and have more features (but I >>> can't prove that of course). >>> >>> So basically I'd say that VTK is currently too big and should get >>> smaller, while the community is too small and should get bigger. >>> >>> -Steve >>> >>> >>> On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi >>> wrote: >>> >>>> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci >>>> wrote: >>>> >>>> > One final note. Everyone please keep in mind that while there are >>>> quite a >>>> > lot of contributors to VTK, certain parts of it are developed by only >>>> a few >>>> > people. Core pipeline: I am it at this point. Rendering: by next >>>> year, it >>>> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis >>>> team at >>>> > Kitware does anything with imaging filters. We update them when we >>>> make >>>> > changes to the pipeline or data model but that's it. So some of those >>>> are >>>> > maintained and developed by others or they are some orphaned. This >>>> can only >>>> > be addressed by either encouraging new (or existing) developers to >>>> take >>>> > ownership or by removing those components all together. >>>> >>>> I have tons of plans for the VTK imaging classes, but unfortunately I >>>> have >>>> almost no resources so progress is slow. Some examples: >>>> >>>> 1) Improving both the API and the performance for multi-threading. >>>> Last year I worked with an intern to improve load sharing. Never had >>>> time to finish, because it wasn't the intern's main project. >>>> >>>> 2) Basic linear image registration in VTK. I've finished it and it's >>>> very robust (been using it for years), but refactoring so that it can >>>> be contributed to VTK is an evening/weekend project and hence is >>>> moving slowly. >>>> >>>> 3) Better image iterators. I have a nice image iterator that iterates >>>> over arbitrary shapes and also provides coordinate info while it >>>> iterates. I'd love to develop this further and contribute it, and I'd >>>> especially love to wrap it, but it's out in left field as far as my >>>> day job goes. >>>> >>>> 4) Better filters for going back and forth between image data and >>>> polydata. Lots of people use my vtkPolyDataToImageStencil filter, >>>> but it has faults and I know exactly how to fix them, but I'll have to >>>> wait until it comes up as a priority for one of my work projects. >>>> >>>> 5) Finally, a better overall structure for the imaging pipeline, >>>> focused on the basics: >>>> a) scalar operation "functors" that can be plugged into filters >>>> b) interpolators, which I've already committed >>>> c) good image "region" descriptors (like my vtkImageStencilData) >>>> d) connectivity & morphological operations, I've got lots of >>>> un-committed stuff >>>> e) a replacement for the lousy vtkImageMathematics filter >>>> >>>> Ideally I should write out a big roadmap (the items mentioned above >>>> is just a fraction of the total), but it would be depressing because so >>>> much of it feels like it's nothing more than a pipe dream. >>>> >>>> And, as Berk mentioned, there isn't anyone in Kitware for me to >>>> directly work with on this stuff. And all the other VTK imaging >>>> developers outside of Kitware are content to keep their work to >>>> themselves, without contributing back to the VTK core. Or at least, >>>> that's the way it looks from my vantage point. >>>> >>>> - David >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/vtk-developers >>>> >>>> >>>> >>>> The information in this e-mail is intended only for the person to whom >>>> it is >>>> addressed. If you believe this e-mail was sent to you in error and the >>>> e-mail >>>> contains patient information, please contact the Partners Compliance >>>> HelpLine at >>>> http://www.partners.org/complianceline . If the e-mail was sent to you >>>> in error >>>> but does not contain patient information, please contact the sender and >>>> properly >>>> dispose of the e-mail. >>>> >>>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> 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 > > 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 Thu Aug 28 12:07:10 2014 From: dlrdave at aol.com (David Cole) Date: Thu, 28 Aug 2014 12:07:10 -0400 (EDT) Subject: [vtk-developers] Driving away your existing developers In-Reply-To: <20140828150749.1061007759@mail.rogue-research.com> References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> <20140828150749.1061007759@mail.rogue-research.com> Message-ID: <8D190F141E2A9DF-1A54-39495@webmail-m205.sysops.aol.com> There is this: http://vtk.org/gitweb?p=VTK.git;a=shortlog;h=refs/heads/master Available via rss here: http://vtk.org/gitweb?p=VTK.git;a=rss;h=refs/heads/master Better than an email list in my opinion... D From berk.geveci at kitware.com Thu Aug 28 13:49:36 2014 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 28 Aug 2014 13:49:36 -0400 Subject: [vtk-developers] Attracting next generation of developers In-Reply-To: References: Message-ID: Hi David and other, > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. Here is my attempt to respond to these: http://www.kitware.com/blog/home/post/728 -berk On Wed, Aug 27, 2014 at 9:13 AM, David Gobbi wrote: > The most important thing is to engage the community. Developers will > be very forgiving about the process as long as you keep them engaged. > > Community engagement requires: > > - Responsive communication. You don't need to always have the answer, > you just need to not be silent. > > - Dedication. Share your dreams and show that you care about the > future. Help your employees to do the same. > > - Transparency. Lay out the roadmap for all to see. Summarize > important development meetings on the wiki. > > You got this NIH grant, so far I see OpenGL2 and community outreach > as aims, but for the most part I'm in the dark about your plans. When > developers are kept in the dark, they feel like they're being shut out. > > > There are several potential pools of developers: > > 1) VTK developers that currently hoard their code instead of > contributing it back to VTK. This is a huge pool of capable > developers. As John indicated in his email from this morning, > process is important but the key is simple: when these people > want to contribute, don't flat-out ignore them! > > 2) Companies for whom VTK is a core tool, and who therefore have a > stake in its development. Really, these are the same as (1) except > that they often have more resources. > > 3) Big grants and collaborations, where large chunks of development is > done outside of Kitware. These undoubtedly help to increase the pool > of developers, so a the question is, how to keep those developers > engaged and ensure that good results are fed back into VTK. > > 4) Young hot-shots who see VTK as just the thing they need for their > new project. For them, having a "Cool and Hip" VTK is important, but > the three bullet points at the top of this email are much, much more > important. > > I've got tons more that I could ramble on about, but it's time for > breakfast (it's still 7am here in western Canada). > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wascott at sandia.gov Thu Aug 28 16:59:54 2014 From: wascott at sandia.gov (Scott, W Alan) Date: Thu, 28 Aug 2014 20:59:54 +0000 Subject: [vtk-developers] [EXTERNAL] Re: Driving away your existing developers In-Reply-To: References: <50320452A334BD42A5EC72BAD214509916C079B2@MBX210.d.ethz.ch> Message-ID: Berk/all, I have read this thread with interest, and have been impressed with how open and honest everyone has been. We have a problem, we discuss the problem, we find fixes for the problem. After discussing these issues with my local team, one comment came up over and over again. I realize that the VTK workflow and this thread are different than ParaView, but since my experience is with ParaView, I will comment accordingly. Further, I realize that the two projects have different needs, but I think the following comments still apply. Although the current procedures do have issues slowing down community contributions, they also have strengths. This is true for ParaView, and I assume for VTK. I have been doing a lot of testing of ParaView for the upcoming 4.2 release, and ParaView is amazingly ?clean? at this point. GUI?s are clear, workflows are simple (or as simple as can be), lots of stuff gets tested in the dashboards, and everything just works (well, most things just work). I am now somewhat surprised when I find bugs, as opposed to the past, where I was surprised when I didn?t. Numerous years ago, before development was reviewed before moving it into head, it was always a crap shoot when updating. Now, it is rare that Master isn?t in a state that is release candidate quality. And I believe that Master should always be in a state that is release candidate quality. My executive summary is this: as we move forward, let?s make sure we don?t lose the processes and controls that have given us the quality products we currently have. my $0.02. Alan From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci Sent: Wednesday, August 27, 2014 7:11 AM To: Ronald R?mer Cc: VTK Developers Subject: [EXTERNAL] Re: [vtk-developers] Driving away your existing developers You are both absolutely right. The review process is broken when it comes to accepting patches from the community. It is broken in 3 ways: 1. As Kitware, we haven't put the right attention to reviewing contributed code from top down (i.e. me and other managers using project resources and asking developers to review contributed work). Even when we have specific projects under which this can be done, we favor developing new code to reviewing contributions. 2. As individual contributors to VTK and ParaView, many of the Kitware developers are focused on their primary goals. We haven't built the open source community spirit as well as we can. Part of this needs to be done by the larger community with encouragement by senior folks (not just ones at Kitware). 3. As others pointed out, there is not enough emphasis and encouragement in reviewing code by the larger community. My code would languish in Gerrit if I didn't have the ability to walk to someone next door and ask them to review it please. David Gobbi and others had suggestions on how to encourage the larger community to be more involved in reviewing. My opinion is that this all boils down to making people feel ownership for VTK rather than seeing it as a tool that needs to be patched as necessary for other work or some project goal (deliver x,y and z and you are done). This is not something I can easily force people to do nor is it a top down thing. I am doing my best by encouraging more community engagement, removing barriers from tools and setting an example by contributing in various ways. I'd like to hear suggestions on how to achieve this and what I can do towards this. One idea: more community hack-a-tons. I just sent out a suggestion for addressing issues in the bug tracker. Why not have another one for reviewing code? One final note. Everyone please keep in mind that while there are quite a lot of contributors to VTK, certain parts of it are developed by only a few people. Core pipeline: I am it at this point. Rendering: by next year, it will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at Kitware does anything with imaging filters. We update them when we make changes to the pipeline or data model but that's it. So some of those are maintained and developed by others or they are some orphaned. This can only be addressed by either encouraging new (or existing) developers to take ownership or by removing those components all together. My 2 cents. -berk On Wed, Aug 27, 2014 at 8:37 AM, Ronald R?mer > wrote: You are absolutely right, in most of your points. None if my commits were previewed by any native kitware developers. Its a pain to find the right previewers and after that none of them will do that job. So it is very hard for a new developer from outside the organization to get the right attention. This is frustrating... _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html 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 Aug 28 18:09:21 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 29 Aug 2014 08:09:21 +1000 Subject: [vtk-developers] Driving away your existing developers Message-ID: It is nice to see all this discussion happening, so keeping the discussion at the higher level. A) When the VTK ARB was set up there were a group of people nominated for topic leads. See: http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process maybe this list needs updating. This feeds into B), below, as these people are often very busy and should be alerted to relevant submissions. B) A while back I asked a question about whether it is possible to get from gerrit regular management reports, see: http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html and I got no replies. I saw that David Cole did a simple enquiry much like I have done. Unless I am really missing something fundamental, and I have searched the web, this does not happen easily with gerrit. I have taken the approach of being notified of all submissions to gerrit and then helping where possible. Obviously on some days this results in a lot of e-mails. What would be really useful would be management style status reports such as: 1) The number of reviews with no reviewers. 2) The number of reviews approved but not submitted. 3) The number of reviews awaiting approval. If these are generated, say monthly, then we should get a good overall picture of what is happening and for example in the case of 1) notify the submitter that reviewers are needed. One of the issues here is that often people submitting new code or updates often do not noiminate reviewers - I guess they either do not read all the documentation for the process or they feel uncomfortable about nominating someone unknown to them. I think putting a process in place like this should help a lot particularly with respect to the issues Dabid Gobbi raised. This would also help community engagement as submitters will know that their submissions are being looked at. So this feeds into Will's comments too. C) As to the complexity of VTK ... hey it is a library and it is complex! It supports many compilers, has many contributions from many different people, has a rigorous somewhat old-fashioned C++ programming style. However it has survived for over 20 years ... so it must be working. Personally I think discussion about moving classes such as vtkITK, vtkTeem, and vtkMRML out may be a bit early, particularly when we must remember that VTK underpins ParaView, and their users need/want(?) this functionality. One other worrying aspect (to me) is the slowness of the migration to VTK 6.x - it seems from the users group lots of people are still using older versions such as VTK 5.8. These people need to be encouraged to upgrade to 6. I know that Steve Piper had issues with Slicer, but, correct me if I am wrong, I did see something along the lines that these issues are largely resolved. D) VTK is not broken and it has many years of life yet! I think if we can implement better management reporting, move people to VTK 6.1 and always encourage migration to the most recent version, then this will reduce the burden on Kitware and also encourage newer developers because the responsiveness will be there. There is always exciting stuff happening in VTK e.g OpenGL2, Numpy, Android stuff etc. We need to get this message out that there is great stuff happening and everybody can help. Anyway this is my take on it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Aug 28 04:16:22 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 28 Aug 2014 08:16:22 -0000 Subject: [vtk-developers] Driving away your existing developers Message-ID: It is nice to see all this discussion happening, so keeping the discussion at the higher level. A) When the VTK ARB was set up there were a group of people nominated for topic leads. See: http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process maybe this list needs updating. This feeds into B), below, as these people are often very busy and should be alerted to relevant submissions. B) A while back I asked a question about whether it is possible to get from gerrit regular management reports, see: http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html and I got no replies. I saw that David Cole did a simple enquiry much like I have done. Unless I am really missing something fundamental, and I have searched the web, this does not happen easily with gerrit. I have taken the approach of being notified of all submissions to gerrit and then helping where possible. Obviously on some days this results in a lot of e-mails. What would be really useful would be management style status reports such as: 1) The number of reviews with no reviewers. 2) The number of reviews approved but not submitted. 3) The number of reviews awaiting approval. If these are generated, say monthly, then we should get a good overall picture of what is happening and for example in the case of 1) notify the submitter that reviewers are needed. One of the issues here is that often people submitting new code or updates often do not noiminate reviewers - I guess they either do not read all the documentation for the process or they feel uncomfortable about nominating someone unknown to them. I think putting a process in place like this should help a lot particularly with respect to the issues Dabid Gobbi raised. This would also help community engagement as submitters will know that their submissions are being looked at. So this feeds into Will's comments too. C) As to the complexity of VTK ... hey it is a library and it is complex! It supports many compilers, has many contributions from many different people, has a rigorous somewhat old-fashioned C++ programming style. However it has survived for over 20 years ... so it must be working. Personally I think discussion about moving classes such as vtkITK, vtkTeem, and vtkMRML out may be a bit early, particularly when we must remember that VTK underpins ParaView, and their users need/want(?) this functionality. One other worrying aspect (to me) is the slowness of the migration to VTK 6.x - it seems from the users group lots of people are still using older versions such as VTK 5.8. These people need to be encouraged to upgrade to 6. I know that Steve Piper had issues with Slicer, but, correct me if I am wrong, I did see something along the lines that these issues are largely resolved. D) VTK is not broken and it has many years of life yet! I think if we can implement better management reporting, move people to VTK 6.1 and always encourage migration to the most recent version, then this will reduce the burden on Kitware and also encourage newer developers because the responsiveness will be there. There is always exciting stuff happening in VTK e.g OpenGL2, Numpy, Android stuff etc. We need to get this message out that there is great stuff happening and everybody can help. Anyway this is my take on it. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: