From mathieu.westphal at kitware.com  Thu Sep  1 03:59:39 2016
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Thu, 1 Sep 2016 09:59:39 +0200
Subject: [vtk-developers] In Parallel,
	how to check if data is distributed across nodes.
Message-ID: <CAC2t4US9rQoq9xDNq98RDJeVhjHrbpsx4UJJA3v2nGV7aPLYSA@mail.gmail.com>

Hello

I would like to know if there is way to to check if the input of the filter
is distributed accross nodes

In my case I have two filter, a typical pipeline looks like this

- Input
  |- Filter 1
    |- Filter2
  |- Filter 2

Input is not parallel aware, so its output will be replicated across nodes,
while filter 1 is, so Filter 1 output can be ditributed across nodes in
parallel.

How could filter2 know if its input is distributed or not ?
I tried to check for CAN_HANDLE_PIECE_REQUEST but without success (with
ParaView).

Thanks a lot

Mathieu Westphal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/d440c85b/attachment.html>

From ken.martin at kitware.com  Thu Sep  1 12:33:08 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Thu, 1 Sep 2016 12:33:08 -0400
Subject: [vtk-developers] Crash with OpenGL2 Renderer only in
 vtkOpenGLBufferObject destructor.
In-Reply-To: <6917D6CD-4DA5-4C4F-9C38-6B19C2846DBA@rogue-research.com>
References: <E00D7B9B-DD13-4F75-8A39-BECCBAA42B2E@rogue-research.com>
 <CANXz0Sar2AHEQ-5ceVmyemF9fUFU=jVYztc_3cOobO+6iRtm4w@mail.gmail.com>
 <C31F4F91-0A45-4651-896D-7BE75AFF5B70@rogue-research.com>
 <CANXz0SaZyrcyHmbozkXzV0PFBwCbnS295smG92zpTGeeGmyj4w@mail.gmail.com>
 <5F999F4D-AD50-4514-B4D7-7676D060DB82@rogue-research.com>
 <8A3D6FC5-66B2-4EE6-BC75-B9190F6A0BDB@rogue-research.com>
 <20160825201714.405989593@mail.rogue-research.com>
 <CANXz0SY65LWJCXxNpHRJYSbW_pY5PRtEsG3WiSsmQijtSMqD+g@mail.gmail.com>
 <6917D6CD-4DA5-4C4F-9C38-6B19C2846DBA@rogue-research.com>
Message-ID: <CANXz0SYSSZiCGcLi3qqpd4SmyR9gCax4j_6_nAj9R06T9KR0_Q@mail.gmail.com>

Got it, I'll take a look. - Ken

On Wed, Aug 31, 2016 at 3:57 PM, Seun Odutola <seun at rogue-research.com>
wrote:

> Thanks for the detailed response.
>
> We have created a simple test app that mimics our main app in order to
> simplify the task of debugging and still the crash reproduces itself.  On
> reviewing our test app alongside your response I can say that we are not
> violating any of the warnings / points stated. No actors are being shared
> between render windows, nor mappers. Each window has its actor and mappers
> separated (thus they act as standalone).
>
> Recall that our crash occurs when setting the mapper of an actor (changing
> its previous mapper).
>
> Our application is Mac-based and there are two main ways to draw on OS X:
> via NSView or via CALayer.  It seems the crash only occurs when we draw via
> CAOpenGLLayer and not when using NSView.  This is mysterious to us.
>
> Our test app is based on the VTK/Examples/GUI/Cocoa sample.  Do you think
> you could take a look?  We annotated the interesting bits with "Ken"
> comments.  It's here:
>
> https://www.rogue-research.com/Foo.zip
>
> To reproduce the crash:
>  - launch the app
>  - click ?create actor" next to one vtk renderwindow
>  - click "X" next to the other vtk renderwindow
>  - click ?swap mapper" next to the first vtk render window
>
>
> p.s: I would also like to know from your previous response ?You would need
> to call release graphics resources every time you switch which window is
> active to make sure the buffers etc all rebuilt? - does this also mean for
> instance if we have 2 render windows and we close our which in turns makes
> the last one active do we need to call release graphics resources on the
> one just terminated? Just wondering.
>
>
>
> On Aug 25, 2016, at 7:12 PM, Ken Martin <ken.martin at kitware.com> wrote:
>
> - actors are tied to a particular render window
>>   - thus they can't be added to two render windows, or moved between two,
>> etc.
>>
>
> Essentially yes, mainly because an actor has a mapper and mappers should
> not be shared between windows.
>
>
>> - mappers are likewise tied to a particular render window
>>
>
> Yes. Mappers create buffer objects that are tied to a window's OpenGL
> context. Right now we do not support sharing buffers between contexts (it
> could be added) so having the same mapper in two windows would either cause
> the buffers to be rebuilt and sent down every frame or an OpenGL error. You
> could share an actor/mapper between two windows if you knew only one would
> active at a time. You would need to call release graphics resources every
> time you switch which window is active to make sure the buffers etc all
> rebuilt. But the general answer is they are not designed to be shared.
>
>
>> - it is permitted to change an actor's mapper
>>
>
> Yes, to a new mapper it should be fine. If reusing an existing mapper from
> another window you must call ReleaseGraphicsResources before using it in a
> different window.
>
>
>> - a single mapper can be shared by multiple actors
>>
>>
> Uh. Maybe :-) So a single mapper, shared by multiple actors in the same
> window (they can be in different renderers) should not crash. My concern is
> that the rendering process keeps track of a lot of modified times to know
> when to rebuild or change "things". With multiple actors sharing the same
> mapper you may either end up with changes not being reflected or the mapper
> rebuilding every time. For example if you had two actors, two properties,
> one mapper. One property is set to wireframe, the other to surface. It
> might well work, but the mapper would be rebuilding the IBOs every single
> frame because it uses different IBOs for wireframe versus surface.
>
> Is that all correct?
>>
>>
> Let me try to add some meta comments here that may help. Actors are light
> weight, feel free to make two if you need two. Making thousands is a
> different story but generally there is no performance advantage to sharing
> them. Same with lights, and properties.
>
> Mappers hold and build a lot of buffers and those buffers are heavily
> dependent on the properties/etc. Mappers can consume a lot of memory if
> their data is large so I can see the desire to share them if you want the
> same geometry in multiple windows or viewports. The mapper is not really
> coded to be shared. If you have a use case where sharing a mapper would be
> good then the right solution would be to add some sort of buffer sharing
> cache in VTK. I would like to see that at some point as it has value and
> doesn't seem crazy hard.
>
> If you are creating/rendering thousands of separate items, then the right
> solution depends on the specifics our your situation. For example,
> glyph3dmapper is great at drawing thousands of the same geometry in
> different places, with different colors, and even different
> orientations/scales. It can do it very quickly and with a low memory
> footprint. Creating actors for all of those would be far more costly.
> Thousands of spheres/cylinders, the OpenGLSphereMapper or
> OpenGLCylinderMapper etc. Lots of different geometry with different
> visibility/color vtkCompositePolyDataMapper2 is the best choice.
>
> Hope that Helps
> Ken
>
>
>
>
>> Thanks,
>>
>> Sean
>>
>>
>> On Thu, 11 Aug 2016 14:31:31 -0400, Seun Odutola said:
>>
>> >Hi Ken,
>> >
>> >I have a scenario where I have an actor and a mapper connected to it (so
>> >in the application window it renders i.e: a sphere). The user has the
>> >ability to change the shape (to cube for example) via the UI, so
>> >internally this is what I?m doing: I have an actor that I keep around,
>> >when the user changes the shape, I just create a new mapper and set the
>> >actor?s mapper directly to the new one (not calling the
>> >ReleaseGraphicsResources).
>> >
>> >First, is this reasonable? Or every time I need to create a new mapper
>> >is it best to also create a new actor to connect it to? or does it
>> >suffice to just swap the actor?s mapper by calling SetMapper()? In the
>> >latter case, then one needs to call ReleaseGraphicsResources on the
>> >previous mapper prior to setting up a new one, right?
>> >
>> >Relatedly, I would like to know for the sake of clarity if mappers can
>> >be shared between actors; that is, is the relationship of an actor and
>> >its mapper a 1 to 1 relationship?
>> >
>> >Regards,
>> >   Seun
>> >
>> >> On Aug 11, 2016, at 11:52 AM, Seun Odutola <seun at rogue-research.com>
>> wrote:
>> >>
>> >> Thanks for the expeditious and detailed response Ken, I truly
>> >appreciate it. Perfect, this is exactly what I thought but needed the
>> >opinion of someone more experienced. I had a closer look at vtkActor and
>> >noticed how it checks the validity of it?s Mapper prior to releasing it
>> >(in its release graphics resource function) proof that it indeed needs
>> >to be released via calling ReleaseGraphicsResources sometime down the
>> >line. Thanks
>> >>
>> >> Regards,
>> >>    Seun.
>> >>
>> >>> On Aug 11, 2016, at 11:44 AM, Ken Martin <ken.martin at kitware.com
>> ><mailto:ken.martin at kitware.com>> wrote:
>> >>>
>> >>> Yes you definitely want to call ReleaseGraphicsResources when you are
>> >done using a graphics object, but are not done using its window.
>> >Normally VTK handles this for you so you do not have to worry about it.
>> >>>
>> >>> Many classes in VTK create and hold onto OpenGL resources. At some
>> >point those resources need to be freed. Normally before an OpenGL
>> >context/window is destroyed it will call ReleaseGraphicsResources on
>> >everything connected to it so that they are all freed before it releases
>> >the context. But if you have detached a mapper from the RenderWindow/
>> >Renderer/Actor (but not yet deleted it) then that does not happen. Then
>> >at some other point that mapper tries to free its resources but the
>> >context that owned them is already gone causing an error.
>> >>>
>> >>> Thanks
>> >>> Ken
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Aug 11, 2016 at 11:33 AM, Seun Odutola <seun at rogue-
>> >research.com <mailto:seun at rogue-research.com>> wrote:
>> >>> Hi Ken,
>> >>>
>> >>>     Thanks for the suggestion. I do have a little question though, is
>> >it a necessary convention to call release graphics resources on the old
>> >mapper prior to setting a new one? I was wondering judging from your
>> >statement (quick fix) if this was just a hack.
>> >>>
>> >>> Regards,
>> >>>     Seun
>> >>>> On Aug 8, 2016, at 1:00 PM, Ken Martin <ken.martin at kitware.com
>> ><mailto:ken.martin at kitware.com>> wrote:
>> >>>>
>> >>>> How do you change the mapper? Do you immediately destroy the old
>> >mapper or leave it around for  later? I suspect the old mapper is
>> >getting destroyed later than it should. One thing you can try as a quick
>> >fix is
>> >>>>
>> >>>> actor->SetMapper(shiny new mapper);
>> >>>> oldMapper->ReleaseGraphicsResources(renWin or NULL if you don;t have
>> >the window handy)
>> >>>> ...
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, Aug 4, 2016 at 3:21 PM, Seun Odutola <seun at rogue-
>> >research.com <mailto:seun at rogue-research.com>> wrote:
>> >>>> Hello everyone,
>> >>>>
>> >>>>       I have a crash that occurs in my application when running vtk
>> >with the GL2 rendered enabled but not with GL1. So here is the
>> >situation, in my program when I change the shape of my poly data mapper,
>> >basically setting the mapper of an actor in my scene to a new poly data
>> >mapper it results in a crash.  The crash is  situated in
>> >vtkOpenGLBufferObject?s destructor, specifically the deletion of the
>> >Internal?s handle. I have tried to verify if the handle is valid prior
>> >to reaching the destructor which it seems to be, my main concern is if
>> >the handle is filled with garbage (a non-zero value) it might
>> >effectively pass the test condition and try to invoke glDeleteBuffer.
>> >Has anyone experienced anything similar to this?
>> >>>>
>> >>>> Regards,
>> >>>>    Seun
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/94f6cc8d/attachment-0001.html>

From david.gobbi at gmail.com  Thu Sep  1 13:18:31 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 1 Sep 2016 11:18:31 -0600
Subject: [vtk-developers] Which compilers to use "extern template" with
Message-ID: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>

Hi David,

You've been playing around with the "extern template" stuff for longer than
I have, so I'm wondering if you can share some experience.

It seems that restricting "extern template" to MSVC 2015 and up would
reduce or eliminate the need for "#pragma warning".  Would it be a bad
thing if we stopped using "extern template" with MSVC 2008, 2010, etc?  The
reason that I ask is that, as I expand the use of "extern template" to
other parts of VTK, I don't want to have to add "#pragma warning" every
time.

For clang and gcc, I was only planning to use "extern template" when
-std=c++11 because otherwise clang generates a warning about this being a
"c++11 feature".

On the other hand I could bite the bullet and also use "extern template"
for pre-c++11 builds, and insert pragmas into a whole bunch of source
files (probably 20 or so) to silence the warnings.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/3b6de934/attachment.html>

From berk.geveci at kitware.com  Thu Sep  1 13:31:27 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 1 Sep 2016 13:31:27 -0400
Subject: [vtk-developers] Which compilers to use "extern template" with
In-Reply-To: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>
References: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>
Message-ID: <CAE32kpV-gc-Rt+Jtm1CQe1zeCV==DekAjVXL0x+WaOLdsvo5mg@mail.gmail.com>

I don't fully follow this conversation but I wanted to remind folks that we
will require C++ 11 support at the end of this year (or beginning of 2017).
Given that we are only a few months from that, I wouldn't spend too much
energy in fixing warnings on platforms we will stop supporting soon.

Best,
-berk

On Thu, Sep 1, 2016 at 1:18 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi David,
>
> You've been playing around with the "extern template" stuff for longer
> than I have, so I'm wondering if you can share some experience.
>
> It seems that restricting "extern template" to MSVC 2015 and up would
> reduce or eliminate the need for "#pragma warning".  Would it be a bad
> thing if we stopped using "extern template" with MSVC 2008, 2010, etc?  The
> reason that I ask is that, as I expand the use of "extern template" to
> other parts of VTK, I don't want to have to add "#pragma warning" every
> time.
>
> For clang and gcc, I was only planning to use "extern template" when
> -std=c++11 because otherwise clang generates a warning about this being a
> "c++11 feature".
>
> On the other hand I could bite the bullet and also use "extern template"
> for pre-c++11 builds, and insert pragmas into a whole bunch of source
> files (probably 20 or so) to silence the warnings.
>
>  - David
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/fa188509/attachment.html>

From david.lonie at kitware.com  Thu Sep  1 13:41:16 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 1 Sep 2016 13:41:16 -0400
Subject: [vtk-developers] Which compilers to use "extern template" with
In-Reply-To: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>
References: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>
Message-ID: <CA+=e1osLAot+qvLcq5p15KNcskRvKZd7DoKvEMX7+KK1uH96mw@mail.gmail.com>

On Thu, Sep 1, 2016 at 1:18 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi David,
>
> You've been playing around with the "extern template" stuff for longer than
> I have, so I'm wondering if you can share some experience.

The extent of my understanding of this syntax is that means a
particular template instantiation will be available at link time, and
thus doesn't need to be compiled into the current translation unit.

> It seems that restricting "extern template" to MSVC 2015 and up would reduce
> or eliminate the need for "#pragma warning".  Would it be a bad thing if we
> stopped using "extern template" with MSVC 2008, 2010, etc?  The reason that
> I ask is that, as I expand the use of "extern template" to other parts of
> VTK, I don't want to have to add "#pragma warning" every time.

I think you're talking about the oddities of the MSVC-specific blocks
in AOS/SOADataArrayTemplate, correct? The only practical difference I
notice is that these are also explicitly exported. I'm not entirely
sure the warning pragmas are still necessary on the versions of MSVC
we support.

Brad (cc'd) might know more, IIRC he originally wrote that block and
tracked down the issues surrounding this.

> For clang and gcc, I was only planning to use "extern template" when
> -std=c++11 because otherwise clang generates a warning about this being a
> "c++11 feature".

This sounds reasonable, and might allow us to eliminate the test for
_MINGW_, since I suspect those problems are actually an issue with
older GCC, not necessarily MinGW itself.

> On the other hand I could bite the bullet and also use "extern template" for
> pre-c++11 builds, and insert pragmas into a whole bunch of source files
> (probably 20 or so) to silence the warnings.

I'd vote for limiting these to C++11 builds rather than adding pragmas
all over, as long as we can get away with it. I don't think non-C++11
builds would complain about them missing (with the possible exception
of MSVC), and the worst case scenario is a slightly longer compile
time as the templates are emitted in each translation unit (and
subsequently stripped by the linker).

Dave

From david.gobbi at gmail.com  Thu Sep  1 13:47:15 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 1 Sep 2016 11:47:15 -0600
Subject: [vtk-developers] Which compilers to use "extern template" with
In-Reply-To: <CA+=e1osLAot+qvLcq5p15KNcskRvKZd7DoKvEMX7+KK1uH96mw@mail.gmail.com>
References: <CANwS1=EDXzab4Yr4fzNdnBX=K0S=wXcpoDvD2XyJm04W-o-K_A@mail.gmail.com>
 <CA+=e1osLAot+qvLcq5p15KNcskRvKZd7DoKvEMX7+KK1uH96mw@mail.gmail.com>
Message-ID: <CANwS1=EQJ+Nik3Ev27OiC3TkCACXbuQ0eoHm2QNxCj-h3OX_wA@mail.gmail.com>

Thanks Berk, David.

I'll move forward with restricting VTK_USE_EXTERN_TEMPLATE to c++11
builds.  When I get around to modifying the existing AOS/SOA extern
template declarations, I'll ping Brad from the MR so that he can
double-check my work.

 - David


On Thu, Sep 1, 2016 at 11:41 AM, David Lonie <david.lonie at kitware.com>
wrote:

> On Thu, Sep 1, 2016 at 1:18 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> > Hi David,
> >
> > You've been playing around with the "extern template" stuff for longer
> than
> > I have, so I'm wondering if you can share some experience.
>
> The extent of my understanding of this syntax is that means a
> particular template instantiation will be available at link time, and
> thus doesn't need to be compiled into the current translation unit.
>
> > It seems that restricting "extern template" to MSVC 2015 and up would
> reduce
> > or eliminate the need for "#pragma warning".  Would it be a bad thing if
> we
> > stopped using "extern template" with MSVC 2008, 2010, etc?  The reason
> that
> > I ask is that, as I expand the use of "extern template" to other parts of
> > VTK, I don't want to have to add "#pragma warning" every time.
>
> I think you're talking about the oddities of the MSVC-specific blocks
> in AOS/SOADataArrayTemplate, correct? The only practical difference I
> notice is that these are also explicitly exported. I'm not entirely
> sure the warning pragmas are still necessary on the versions of MSVC
> we support.
>
> Brad (cc'd) might know more, IIRC he originally wrote that block and
> tracked down the issues surrounding this.
>
> > For clang and gcc, I was only planning to use "extern template" when
> > -std=c++11 because otherwise clang generates a warning about this being a
> > "c++11 feature".
>
> This sounds reasonable, and might allow us to eliminate the test for
> _MINGW_, since I suspect those problems are actually an issue with
> older GCC, not necessarily MinGW itself.
>
> > On the other hand I could bite the bullet and also use "extern template"
> for
> > pre-c++11 builds, and insert pragmas into a whole bunch of source files
> > (probably 20 or so) to silence the warnings.
>
> I'd vote for limiting these to C++11 builds rather than adding pragmas
> all over, as long as we can get away with it. I don't think non-C++11
> builds would complain about them missing (with the possible exception
> of MSVC), and the worst case scenario is a slightly longer compile
> time as the templates are emitted in each translation unit (and
> subsequently stripped by the linker).
>
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160901/062b04a1/attachment.html>

From weifeng0715 at gmail.com  Fri Sep  2 11:13:56 2016
From: weifeng0715 at gmail.com (weifeng0715)
Date: Fri, 2 Sep 2016 08:13:56 -0700 (MST)
Subject: [vtk-developers] Animate the trajectories
Message-ID: <1472829236502-5740116.post@n5.nabble.com>

Hi,
   I want to know how to animate the trajectories as shown in the movie:
https://www.youtube.com/watch?v=78U0_XcFP_I
   I have the time steps and the trajectories at each time step.





--
View this message in context: http://vtk.1045678.n5.nabble.com/Animate-the-trajectories-tp5740116.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From mathieu.westphal at kitware.com  Mon Sep  5 04:10:14 2016
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Mon, 5 Sep 2016 10:10:14 +0200
Subject: [vtk-developers] VTK/Paraview Courses in October
In-Reply-To: <CAC2t4USH9Vp85YCWtu+Uw9kvbPrOUVQwFk7q2T0JOJXfGoZKdA@mail.gmail.com>
References: <CAC2t4USH9Vp85YCWtu+Uw9kvbPrOUVQwFk7q2T0JOJXfGoZKdA@mail.gmail.com>
Message-ID: <CAC2t4UQGrpbH1Ef+bZZKZVqoRiMKosytv_4H6peER9hUVFSwgQ@mail.gmail.com>

Hello
Kitware will be holding a 2-day VTK and ParaView course on October 11th and
12th 2016 in Lyon, France.

Please visit our web site for more information and registration details at
VTK (English) : http://training.kitware.fr/browse/130
VTK (French) : http://formations.kitware.fr/browse/130
ParaView (English) : http://training.kitware.fr/browse/131
ParaView (French) : http://formations.kitware.fr/browse/131


Note that the course will be taught in English. If you have any question,
please contact us at formations at http://www.kitware.fr

Thank you,

Mathieu Westphal

Mathieu Westphal

On Wed, Jul 6, 2016 at 4:49 PM, Mathieu Westphal <
mathieu.westphal at kitware.com> wrote:

> Hello
> Kitware will be holding a 2-day VTK and ParaView course on October 11th
> and 12th 2016 in Lyon, France.
>
> Please visit our web site for more information and registration details at
> VTK (English) : http://training.kitware.fr/browse/130
> VTK (French) : http://formations.kitware.fr/browse/130
> ParaView (English) : http://training.kitware.fr/browse/131
> ParaView (French) : http://formations.kitware.fr/browse/131
>
>
> Note that the course will be taught in English. If you have any question,
> please contact us at formations at http://www.kitware.fr
>
> Thank you,
>
> Mathieu Westphal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160905/16b5c5da/attachment.html>

From david.gobbi at gmail.com  Tue Sep  6 10:55:18 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 6 Sep 2016 08:55:18 -0600
Subject: [vtk-developers] Module vtktiff polluting cmake cache
Message-ID: <CANwS1=HQ8paia5ycssgRbxErV9x-OWwvTxhhs9vwFtg8yNjmxw@mail.gmail.com>

Hi All,

There are a whole bunch of cache variables from vtktiff that don't look
like they belong in VTK's CMakeCache.txt.  Could someone clean these up, or
maybe prefix them with TIFF?

ccitt:BOOL=ON
check-ycbcr-subsampling:BOOL=ON
chunky-strip-read:BOOL=OFF
cxx:BOOL=ON
defer-strile-load:BOOL=OFF
extra-warnings:BOOL=OFF
extrasample-as-alpha:BOOL=ON
fatal-warnings:BOOL=OFF
jbig:BOOL=OFF
jpeg:BOOL=OFF
jpeg12:BOOL=OFF
ld-version-script:BOOL=ON
logluv:BOOL=ON
lzma:BOOL=OFF
lzw:BOOL=ON
mdi:BOOL=ON
next:BOOL=ON
old-jpeg:BOOL=OFF
packbits:BOOL=ON
pixarlog:BOOL=ON
strip-chopping:BOOL=ON
thunder:BOOL=ON

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160906/3a1ae75c/attachment.html>

From berk.geveci at kitware.com  Wed Sep  7 11:34:45 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 7 Sep 2016 11:34:45 -0400
Subject: [vtk-developers] Next VTK hackathon
In-Reply-To: <CAE32kpWUGOHDKg2TpWBjRZAQFc=GrfqabyYDFMJ7Ngxd-OJYpA@mail.gmail.com>
References: <CAE32kpV_Qi+ELYVvQ+0gowm23NuD__OX3+zUGKNrq5qKknRj9A@mail.gmail.com>
 <CAE32kpWUGOHDKg2TpWBjRZAQFc=GrfqabyYDFMJ7Ngxd-OJYpA@mail.gmail.com>
Message-ID: <CAE32kpVTns8B_41ukWv_rmoXqwG4LXD0ydYFLY-B9tgp3BZ_yA@mail.gmail.com>

Hi folks,

Just a reminder that our next hackathon will be tomorrowm, 10-5 EDT. If you
will attend, please send me a note. So far, I know of the following people
attending.

* Berk
* Will
* Bill
* Utkarsh
* Michael
* Tristan
* Chet
* Shawn
* Sankhesh
* Aron
* Cory
* Rob
* Ken
* Alvaro
* TJ
* Haocheng

Best,
-berk


On Mon, Aug 22, 2016 at 8:12 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> We are good to go for September 8. We are happy to host people in our
> Clifton Park, NY and Carrboro, NC offfices (please let me know in advance)
> and we will have a Google Hangout open. The link is:
>
> https://hangouts.google.com/hangouts/_/kitware.com/vtk-hackathon
>
> We will start at 10am and will go until 5pm (all EDT).
>
> The focus will be on cleaning up the VTK dashboard and the issue tracker.
>
> Best,
> -berk
>
>
> On Tue, Aug 16, 2016 at 3:36 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> I am thinking that September 8 would be a good date for our next
>> hackathon. I suggest that we primarily focus on the dashboards but also
>> work on the issue tracker. What do you think?
>>
>> Best,
>> -berk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160907/0b881381/attachment.html>

From david.gobbi at gmail.com  Wed Sep  7 14:45:39 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 7 Sep 2016 12:45:39 -0600
Subject: [vtk-developers] MR to reindent VTK's braces
Message-ID: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>

Hi All,

I figured that I might as well push this now, since the new gitlab does a
decent job of displaying it even though it's a ginormous diff:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1911

So now you can go into the future take a peek at VTK after the style change
to the braces. This is marked as a WIP because this isn't something to
spring on people without due warning.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160907/26bc1fcd/attachment.html>

From dave.demarle at kitware.com  Wed Sep  7 15:10:24 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 7 Sep 2016 15:10:24 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
Message-ID: <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>

Excellent. Let's hold of on the merge until after the imminent 7.1 branch.
OK?


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Wed, Sep 7, 2016 at 2:45 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi All,
>
> I figured that I might as well push this now, since the new gitlab does a
> decent job of displaying it even though it's a ginormous diff:
>
> https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>
> So now you can go into the future take a peek at VTK after the style
> change to the braces. This is marked as a WIP because this isn't something
> to spring on people without due warning.
>
>  - David
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160907/76abd256/attachment.html>

From shawn.waldon at kitware.com  Wed Sep  7 16:03:32 2016
From: shawn.waldon at kitware.com (Shawn Waldon)
Date: Wed, 7 Sep 2016 16:03:32 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
Message-ID: <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>

On Wed, Sep 7, 2016 at 3:10 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Excellent. Let's hold of on the merge until after the imminent 7.1 branch.
> OK?
>

Or do we want to merge it before 7.1 so that creating branches to merge
into release won't make their style incompatible with master?

Shawn

>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Wed, Sep 7, 2016 at 2:45 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>
>> Hi All,
>>
>> I figured that I might as well push this now, since the new gitlab does a
>> decent job of displaying it even though it's a ginormous diff:
>>
>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>
>> So now you can go into the future take a peek at VTK after the style
>> change to the braces. This is marked as a WIP because this isn't something
>> to spring on people without due warning.
>>
>>  - David
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160907/a61fc32b/attachment.html>

From ben.boeckel at kitware.com  Wed Sep  7 16:19:57 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 7 Sep 2016 16:19:57 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
Message-ID: <20160907201957.GA5337@megas.kitware.com>

On Wed, Sep 07, 2016 at 16:03:32 -0400, Shawn Waldon wrote:
> On Wed, Sep 7, 2016 at 3:10 PM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
> > Excellent. Let's hold of on the merge until after the imminent 7.1 branch.
> > OK?
> >
> 
> Or do we want to merge it before 7.1 so that creating branches to merge
> into release won't make their style incompatible with master?

Yes, please. Otherwise every branch meant for 7.1 will need a rebase
onto 7.1 after merging into master.

--Ben

From dave.demarle at kitware.com  Thu Sep  8 09:02:09 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 8 Sep 2016 09:02:09 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <20160907201957.GA5337@megas.kitware.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
Message-ID: <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>

How about after 7.1 final then.

That and the reworking of doxygen will disrupt pretty much everyone's
existing branches, so better to come out first as part of 8.0.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Wed, Sep 7, 2016 at 4:19 PM, Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Wed, Sep 07, 2016 at 16:03:32 -0400, Shawn Waldon wrote:
> > On Wed, Sep 7, 2016 at 3:10 PM, David E DeMarle <
> dave.demarle at kitware.com>
> > wrote:
> > > Excellent. Let's hold of on the merge until after the imminent 7.1
> branch.
> > > OK?
> > >
> >
> > Or do we want to merge it before 7.1 so that creating branches to merge
> > into release won't make their style incompatible with master?
>
> Yes, please. Otherwise every branch meant for 7.1 will need a rebase
> onto 7.1 after merging into master.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/af4a7bd1/attachment.html>

From ben.boeckel at kitware.com  Thu Sep  8 09:06:06 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 8 Sep 2016 09:06:06 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
Message-ID: <20160908130606.GA13993@megas.kitware.com>

On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
> How about after 7.1 final then.
> 
> That and the reworking of doxygen will disrupt pretty much everyone's
> existing branches, so better to come out first as part of 8.0.

No, because any branch which is meant for 7.1 then needs two versions:
one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).

--Ben

From dave.demarle at kitware.com  Thu Sep  8 09:08:13 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 8 Sep 2016 09:08:13 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <20160908130606.GA13993@megas.kitware.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
Message-ID: <CANjZAi-ns0MvTkf_igk4oy+S063_EuKYRAagqxXsBH3HGmwkTg@mail.gmail.com>

But 7.1.0 will be released when the merge is made into master.
So the above will be true for anything meant for 7.1.X.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
> > How about after 7.1 final then.
> >
> > That and the reworking of doxygen will disrupt pretty much everyone's
> > existing branches, so better to come out first as part of 8.0.
>
> No, because any branch which is meant for 7.1 then needs two versions:
> one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/1531fafe/attachment.html>

From DLRdave at aol.com  Thu Sep  8 09:10:51 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 8 Sep 2016 09:10:51 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <20160908130606.GA13993@megas.kitware.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
Message-ID: <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>

It would seem better to bite the bullet and do it now unless there is
an extremely urgent deadline for 7.1......

D


On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com> wrote:
> On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>> How about after 7.1 final then.
>>
>> That and the reworking of doxygen will disrupt pretty much everyone's
>> existing branches, so better to come out first as part of 8.0.
>
> No, because any branch which is meant for 7.1 then needs two versions:
> one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).
>
> --Ben
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From brad.king at kitware.com  Thu Sep  8 09:24:36 2016
From: brad.king at kitware.com (Brad King)
Date: Thu, 8 Sep 2016 09:24:36 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
Message-ID: <2fb3e0df-a3d4-b2d2-6ff7-7a9b1813154a@kitware.com>

On 09/08/2016 09:10 AM, David Cole via vtk-developers wrote:
> It would seem better to bite the bullet and do it now unless there is
> an extremely urgent deadline for 7.1......

FWIW CMake did its style conversion just before its 3.6 release
specifically for the reason Ben raised here.  It worked out very
well.

-Brad


From dave.demarle at kitware.com  Thu Sep  8 09:29:03 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 8 Sep 2016 09:29:03 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
Message-ID: <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>

I want to do a release soonish only because:
* 7.0.0 is getting long in the tooth and I've not found any time to do 7.0.1
* It is helpful for ParaView releases if VTK has a recent release to work
from, and PV 5.2 is expected month or so from now.

Why shouldn't we do this now?
* the doxygen update will also be a disruption, so we should combine so
people only go through the pain once
* my vague feelings about whether this should be in a minor release or a
major release, and we know we want a major release very soon.


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:

> It would seem better to bite the bullet and do it now unless there is
> an extremely urgent deadline for 7.1......
>
> D
>
>
> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com>
> wrote:
> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
> >> How about after 7.1 final then.
> >>
> >> That and the reworking of doxygen will disrupt pretty much everyone's
> >> existing branches, so better to come out first as part of 8.0.
> >
> > No, because any branch which is meant for 7.1 then needs two versions:
> > one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).
> >
> > --Ben
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/9eff1025/attachment.html>

From pandia005 at gmail.com  Thu Sep  8 09:33:49 2016
From: pandia005 at gmail.com (Pandia raja)
Date: Thu, 8 Sep 2016 19:03:49 +0530
Subject: [vtk-developers] Reg:How to set Orientation for resliced coronal
	and sagital image
Message-ID: <CAMMPchkY48CDbOoK5zbxuDpFY7eumEbL6ccZ3Rg4pknz1xA3cg@mail.gmail.com>

 Hi,
    Am unable to get the Image Orientation (Patient)(0020,0037) in coronal
and sagital images after reslicing from Axial Images. How to set/get Image
Orientation for the Coronal/Sagital images. I am using the following code
to do the Reslicing.


    vtkImageReslice coronalReslice= new vtkImageReslice();
   coronalReslice.SetInputConnection ( reader.GetOutputPort () );
coronalReslice.SetOutputDimensionality ( 2 );
coronalReslice.SetResliceAxes ( coronalResliceAxes );
coronalReslice.SetInterpolationModeToNearestNeighbor ();
coronalReslice.SetOutputSpacing ( spacing );
coronalReslice.SetOutputExtent ( xyminmax );

vtkDICOMWriter writer = new vtkDICOMWriter ();

writer.SetInputConnection ( coronalReslice.GetOutputPort () );
writer.SetFilePattern (fileName );
writer.Write ();
Thanks,
Pandiyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/0e7a9814/attachment.html>

From berk.geveci at kitware.com  Thu Sep  8 09:34:04 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 8 Sep 2016 09:34:04 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
Message-ID: <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>

One way or another it would be great to choose & announce a date for
merging this. That way, people with existing work will know when potential
conflicts are coming.

On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> I want to do a release soonish only because:
> * 7.0.0 is getting long in the tooth and I've not found any time to do
> 7.0.1
> * It is helpful for ParaView releases if VTK has a recent release to work
> from, and PV 5.2 is expected month or so from now.
>
> Why shouldn't we do this now?
> * the doxygen update will also be a disruption, so we should combine so
> people only go through the pain once
> * my vague feelings about whether this should be in a minor release or a
> major release, and we know we want a major release very soon.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>
>> It would seem better to bite the bullet and do it now unless there is
>> an extremely urgent deadline for 7.1......
>>
>> D
>>
>>
>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com>
>> wrote:
>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>> >> How about after 7.1 final then.
>> >>
>> >> That and the reworking of doxygen will disrupt pretty much everyone's
>> >> existing branches, so better to come out first as part of 8.0.
>> >
>> > No, because any branch which is meant for 7.1 then needs two versions:
>> > one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).
>> >
>> > --Ben
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> >
>> > Search the list archives at: http://markmail.org/search/?q=
>> vtk-developers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>> >
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/8ecc8065/attachment-0001.html>

From robert.maynard at kitware.com  Thu Sep  8 09:54:45 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 8 Sep 2016 09:54:45 -0400
Subject: [vtk-developers] Module vtktiff polluting cmake cache
In-Reply-To: <CANwS1=HQ8paia5ycssgRbxErV9x-OWwvTxhhs9vwFtg8yNjmxw@mail.gmail.com>
References: <CANwS1=HQ8paia5ycssgRbxErV9x-OWwvTxhhs9vwFtg8yNjmxw@mail.gmail.com>
Message-ID: <CAFzjYVo9=tSTq=tAqYq+JB6fr6JVyRgAv5XnmEQYrwEKn26MDg@mail.gmail.com>

Since I was the last person to update the vtktiff module I can go
ahead and clean this up today

On Tue, Sep 6, 2016 at 10:55 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi All,
>
> There are a whole bunch of cache variables from vtktiff that don't look like
> they belong in VTK's CMakeCache.txt.  Could someone clean these up, or maybe
> prefix them with TIFF?
>
> ccitt:BOOL=ON
> check-ycbcr-subsampling:BOOL=ON
> chunky-strip-read:BOOL=OFF
> cxx:BOOL=ON
> defer-strile-load:BOOL=OFF
> extra-warnings:BOOL=OFF
> extrasample-as-alpha:BOOL=ON
> fatal-warnings:BOOL=OFF
> jbig:BOOL=OFF
> jpeg:BOOL=OFF
> jpeg12:BOOL=OFF
> ld-version-script:BOOL=ON
> logluv:BOOL=ON
> lzma:BOOL=OFF
> lzw:BOOL=ON
> mdi:BOOL=ON
> next:BOOL=ON
> old-jpeg:BOOL=OFF
> packbits:BOOL=ON
> pixarlog:BOOL=ON
> strip-chopping:BOOL=ON
> thunder:BOOL=ON
>
>  - David
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From david.gobbi at gmail.com  Thu Sep  8 10:00:34 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 08:00:34 -0600
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
Message-ID: <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>

In general, I'd love to see VTK move to regularly-scheduled minor releases
with firm dates set months in advance :)

On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com> wrote:

> One way or another it would be great to choose & announce a date for
> merging this. That way, people with existing work will know when potential
> conflicts are coming.
>
> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>
>> I want to do a release soonish only because:
>> * 7.0.0 is getting long in the tooth and I've not found any time to do
>> 7.0.1
>> * It is helpful for ParaView releases if VTK has a recent release to work
>> from, and PV 5.2 is expected month or so from now.
>>
>> Why shouldn't we do this now?
>> * the doxygen update will also be a disruption, so we should combine so
>> people only go through the pain once
>> * my vague feelings about whether this should be in a minor release or a
>> major release, and we know we want a major release very soon.
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>>
>>> It would seem better to bite the bullet and do it now unless there is
>>> an extremely urgent deadline for 7.1......
>>>
>>> D
>>>
>>>
>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com>
>>> wrote:
>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>>> >> How about after 7.1 final then.
>>> >>
>>> >> That and the reworking of doxygen will disrupt pretty much everyone's
>>> >> existing branches, so better to come out first as part of 8.0.
>>> >
>>> > No, because any branch which is meant for 7.1 then needs two versions:
>>> > one for master (post-cleanup) and another for 7.1 itself (pre-cleanup).
>>> >
>>> > --Ben
>>> > _______________________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>> >
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/2f156148/attachment.html>

From DLRdave at aol.com  Thu Sep  8 10:42:51 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 8 Sep 2016 10:42:51 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
 <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
Message-ID: <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>

+1

Automatic even. ;-)

Daves on the VTK lists unite!



On Thu, Sep 8, 2016 at 10:00 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> In general, I'd love to see VTK move to regularly-scheduled minor releases
> with firm dates set months in advance :)
>
> On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
>>
>> One way or another it would be great to choose & announce a date for
>> merging this. That way, people with existing work will know when potential
>> conflicts are coming.
>>
>> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <dave.demarle at kitware.com>
>> wrote:
>>>
>>> I want to do a release soonish only because:
>>> * 7.0.0 is getting long in the tooth and I've not found any time to do
>>> 7.0.1
>>> * It is helpful for ParaView releases if VTK has a recent release to work
>>> from, and PV 5.2 is expected month or so from now.
>>>
>>> Why shouldn't we do this now?
>>> * the doxygen update will also be a disruption, so we should combine so
>>> people only go through the pain once
>>> * my vague feelings about whether this should be in a minor release or a
>>> major release, and we know we want a major release very soon.
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>>>>
>>>> It would seem better to bite the bullet and do it now unless there is
>>>> an extremely urgent deadline for 7.1......
>>>>
>>>> D
>>>>
>>>>
>>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com>
>>>> wrote:
>>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>>>> >> How about after 7.1 final then.
>>>> >>
>>>> >> That and the reworking of doxygen will disrupt pretty much everyone's
>>>> >> existing branches, so better to come out first as part of 8.0.
>>>> >
>>>> > No, because any branch which is meant for 7.1 then needs two versions:
>>>> > one for master (post-cleanup) and another for 7.1 itself
>>>> > (pre-cleanup).
>>>> >
>>>> > --Ben
>>>> > _______________________________________________
>>>> > Powered by www.kitware.com
>>>> >
>>>> > Visit other Kitware open-source projects at
>>>> > http://www.kitware.com/opensource/opensource.html
>>>> >
>>>> > Search the list archives at:
>>>> > http://markmail.org/search/?q=vtk-developers
>>>> >
>>>> > Follow this link to subscribe/unsubscribe:
>>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>
>

From berk.geveci at kitware.com  Thu Sep  8 10:49:06 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 8 Sep 2016 10:49:06 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
 <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
 <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>
Message-ID: <CAE32kpWdabT7Mu5cxH6M8R5rvQAiscGjs5UVYDVB+CGrkXdcsQ@mail.gmail.com>

I agree with Dave's (DeMarle) argument that we should do this at the same
time as the Doxygen changes. It would be annoying to have two merge
barriers in a manner of a few months.

-berk

On Thu, Sep 8, 2016 at 10:42 AM, David Cole <DLRdave at aol.com> wrote:

> +1
>
> Automatic even. ;-)
>
> Daves on the VTK lists unite!
>
>
>
> On Thu, Sep 8, 2016 at 10:00 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > In general, I'd love to see VTK move to regularly-scheduled minor
> releases
> > with firm dates set months in advance :)
> >
> > On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> >>
> >> One way or another it would be great to choose & announce a date for
> >> merging this. That way, people with existing work will know when
> potential
> >> conflicts are coming.
> >>
> >> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <
> dave.demarle at kitware.com>
> >> wrote:
> >>>
> >>> I want to do a release soonish only because:
> >>> * 7.0.0 is getting long in the tooth and I've not found any time to do
> >>> 7.0.1
> >>> * It is helpful for ParaView releases if VTK has a recent release to
> work
> >>> from, and PV 5.2 is expected month or so from now.
> >>>
> >>> Why shouldn't we do this now?
> >>> * the doxygen update will also be a disruption, so we should combine so
> >>> people only go through the pain once
> >>> * my vague feelings about whether this should be in a minor release or
> a
> >>> major release, and we know we want a major release very soon.
> >>>
> >>>
> >>> David E DeMarle
> >>> Kitware, Inc.
> >>> R&D Engineer
> >>> 21 Corporate Drive
> >>> Clifton Park, NY 12065-8662
> >>> Phone: 518-881-4909
> >>>
> >>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
> >>>>
> >>>> It would seem better to bite the bullet and do it now unless there is
> >>>> an extremely urgent deadline for 7.1......
> >>>>
> >>>> D
> >>>>
> >>>>
> >>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com>
> >>>> wrote:
> >>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
> >>>> >> How about after 7.1 final then.
> >>>> >>
> >>>> >> That and the reworking of doxygen will disrupt pretty much
> everyone's
> >>>> >> existing branches, so better to come out first as part of 8.0.
> >>>> >
> >>>> > No, because any branch which is meant for 7.1 then needs two
> versions:
> >>>> > one for master (post-cleanup) and another for 7.1 itself
> >>>> > (pre-cleanup).
> >>>> >
> >>>> > --Ben
> >>>> > _______________________________________________
> >>>> > Powered by www.kitware.com
> >>>> >
> >>>> > Visit other Kitware open-source projects at
> >>>> > http://www.kitware.com/opensource/opensource.html
> >>>> >
> >>>> > Search the list archives at:
> >>>> > http://markmail.org/search/?q=vtk-developers
> >>>> >
> >>>> > Follow this link to subscribe/unsubscribe:
> >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >>>> >
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://public.kitware.com/mailman/listinfo/vtk-developers
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/015244ca/attachment-0001.html>

From david.gobbi at gmail.com  Thu Sep  8 11:04:54 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 09:04:54 -0600
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CAE32kpWdabT7Mu5cxH6M8R5rvQAiscGjs5UVYDVB+CGrkXdcsQ@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
 <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
 <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>
 <CAE32kpWdabT7Mu5cxH6M8R5rvQAiscGjs5UVYDVB+CGrkXdcsQ@mail.gmail.com>
Message-ID: <CANwS1=Gbe=TLXcgz-vWob_1ZAVFJ7tOyS7WqrNu5-9DAdP8cCw@mail.gmail.com>

Is anyone working on the Doxygen changes, though?  Unless we have some idea
of when it's going to be done, it shouldn't be influencing decisions about
other merges.

On Thu, Sep 8, 2016 at 8:49 AM, Berk Geveci <berk.geveci at kitware.com> wrote:

> I agree with Dave's (DeMarle) argument that we should do this at the same
> time as the Doxygen changes. It would be annoying to have two merge
> barriers in a manner of a few months.
>
> -berk
>
> On Thu, Sep 8, 2016 at 10:42 AM, David Cole <DLRdave at aol.com> wrote:
>
>> +1
>>
>> Automatic even. ;-)
>>
>> Daves on the VTK lists unite!
>>
>>
>>
>> On Thu, Sep 8, 2016 at 10:00 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>> > In general, I'd love to see VTK move to regularly-scheduled minor
>> releases
>> > with firm dates set months in advance :)
>> >
>> > On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>> >>
>> >> One way or another it would be great to choose & announce a date for
>> >> merging this. That way, people with existing work will know when
>> potential
>> >> conflicts are coming.
>> >>
>> >> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <
>> dave.demarle at kitware.com>
>> >> wrote:
>> >>>
>> >>> I want to do a release soonish only because:
>> >>> * 7.0.0 is getting long in the tooth and I've not found any time to do
>> >>> 7.0.1
>> >>> * It is helpful for ParaView releases if VTK has a recent release to
>> work
>> >>> from, and PV 5.2 is expected month or so from now.
>> >>>
>> >>> Why shouldn't we do this now?
>> >>> * the doxygen update will also be a disruption, so we should combine
>> so
>> >>> people only go through the pain once
>> >>> * my vague feelings about whether this should be in a minor release
>> or a
>> >>> major release, and we know we want a major release very soon.
>> >>>
>> >>>
>> >>> David E DeMarle
>> >>> Kitware, Inc.
>> >>> R&D Engineer
>> >>> 21 Corporate Drive
>> >>> Clifton Park, NY 12065-8662
>> >>> Phone: 518-881-4909
>> >>>
>> >>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>> >>>>
>> >>>> It would seem better to bite the bullet and do it now unless there is
>> >>>> an extremely urgent deadline for 7.1......
>> >>>>
>> >>>> D
>> >>>>
>> >>>>
>> >>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <ben.boeckel at kitware.com
>> >
>> >>>> wrote:
>> >>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>> >>>> >> How about after 7.1 final then.
>> >>>> >>
>> >>>> >> That and the reworking of doxygen will disrupt pretty much
>> everyone's
>> >>>> >> existing branches, so better to come out first as part of 8.0.
>> >>>> >
>> >>>> > No, because any branch which is meant for 7.1 then needs two
>> versions:
>> >>>> > one for master (post-cleanup) and another for 7.1 itself
>> >>>> > (pre-cleanup).
>> >>>> >
>> >>>> > --Ben
>> >>>> > _______________________________________________
>> >>>> > Powered by www.kitware.com
>> >>>> >
>> >>>> > Visit other Kitware open-source projects at
>> >>>> > http://www.kitware.com/opensource/opensource.html
>> >>>> >
>> >>>> > Search the list archives at:
>> >>>> > http://markmail.org/search/?q=vtk-developers
>> >>>> >
>> >>>> > Follow this link to subscribe/unsubscribe:
>> >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Powered by www.kitware.com
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> http://www.kitware.com/opensource/opensource.html
>> >>>
>> >>> Search the list archives at: http://markmail.org/search/?q=
>> vtk-developers
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers
>> >>>
>> >>>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/c7099f9b/attachment.html>

From dave.demarle at kitware.com  Thu Sep  8 12:10:14 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 8 Sep 2016 12:10:14 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANwS1=Gbe=TLXcgz-vWob_1ZAVFJ7tOyS7WqrNu5-9DAdP8cCw@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
 <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
 <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>
 <CAE32kpWdabT7Mu5cxH6M8R5rvQAiscGjs5UVYDVB+CGrkXdcsQ@mail.gmail.com>
 <CANwS1=Gbe=TLXcgz-vWob_1ZAVFJ7tOyS7WqrNu5-9DAdP8cCw@mail.gmail.com>
Message-ID: <CANjZAi89cBN8jSDYXufRiP__75wZ3nsExL7uKQpm2pBPqAO7tg@mail.gmail.com>

To first approximation this doesn't appear hard to do:

perl Utilities/Doxygen/doc_header2doxygen.pl  --to ~/tmp $VTKSRC
cp -r ~/tmp $VTKSRC

There is probably more to it than that. I'll poke around now.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Sep 8, 2016 at 11:04 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Is anyone working on the Doxygen changes, though?  Unless we have some
> idea of when it's going to be done, it shouldn't be influencing decisions
> about other merges.
>
> On Thu, Sep 8, 2016 at 8:49 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> I agree with Dave's (DeMarle) argument that we should do this at the same
>> time as the Doxygen changes. It would be annoying to have two merge
>> barriers in a manner of a few months.
>>
>> -berk
>>
>> On Thu, Sep 8, 2016 at 10:42 AM, David Cole <DLRdave at aol.com> wrote:
>>
>>> +1
>>>
>>> Automatic even. ;-)
>>>
>>> Daves on the VTK lists unite!
>>>
>>>
>>>
>>> On Thu, Sep 8, 2016 at 10:00 AM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>> > In general, I'd love to see VTK move to regularly-scheduled minor
>>> releases
>>> > with firm dates set months in advance :)
>>> >
>>> > On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com>
>>> wrote:
>>> >>
>>> >> One way or another it would be great to choose & announce a date for
>>> >> merging this. That way, people with existing work will know when
>>> potential
>>> >> conflicts are coming.
>>> >>
>>> >> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <
>>> dave.demarle at kitware.com>
>>> >> wrote:
>>> >>>
>>> >>> I want to do a release soonish only because:
>>> >>> * 7.0.0 is getting long in the tooth and I've not found any time to
>>> do
>>> >>> 7.0.1
>>> >>> * It is helpful for ParaView releases if VTK has a recent release to
>>> work
>>> >>> from, and PV 5.2 is expected month or so from now.
>>> >>>
>>> >>> Why shouldn't we do this now?
>>> >>> * the doxygen update will also be a disruption, so we should combine
>>> so
>>> >>> people only go through the pain once
>>> >>> * my vague feelings about whether this should be in a minor release
>>> or a
>>> >>> major release, and we know we want a major release very soon.
>>> >>>
>>> >>>
>>> >>> David E DeMarle
>>> >>> Kitware, Inc.
>>> >>> R&D Engineer
>>> >>> 21 Corporate Drive
>>> >>> Clifton Park, NY 12065-8662
>>> >>> Phone: 518-881-4909
>>> >>>
>>> >>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>>> >>>>
>>> >>>> It would seem better to bite the bullet and do it now unless there
>>> is
>>> >>>> an extremely urgent deadline for 7.1......
>>> >>>>
>>> >>>> D
>>> >>>>
>>> >>>>
>>> >>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <
>>> ben.boeckel at kitware.com>
>>> >>>> wrote:
>>> >>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>>> >>>> >> How about after 7.1 final then.
>>> >>>> >>
>>> >>>> >> That and the reworking of doxygen will disrupt pretty much
>>> everyone's
>>> >>>> >> existing branches, so better to come out first as part of 8.0.
>>> >>>> >
>>> >>>> > No, because any branch which is meant for 7.1 then needs two
>>> versions:
>>> >>>> > one for master (post-cleanup) and another for 7.1 itself
>>> >>>> > (pre-cleanup).
>>> >>>> >
>>> >>>> > --Ben
>>> >>>> > _______________________________________________
>>> >>>> > Powered by www.kitware.com
>>> >>>> >
>>> >>>> > Visit other Kitware open-source projects at
>>> >>>> > http://www.kitware.com/opensource/opensource.html
>>> >>>> >
>>> >>>> > Search the list archives at:
>>> >>>> > http://markmail.org/search/?q=vtk-developers
>>> >>>> >
>>> >>>> > Follow this link to subscribe/unsubscribe:
>>> >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>> >>>> >
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Powered by www.kitware.com
>>> >>>
>>> >>> Visit other Kitware open-source projects at
>>> >>> http://www.kitware.com/opensource/opensource.html
>>> >>>
>>> >>> Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>> >>>
>>> >>> Follow this link to subscribe/unsubscribe:
>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/8a17fd88/attachment.html>

From utkarsh.ayachit at kitware.com  Thu Sep  8 12:55:04 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 8 Sep 2016 12:55:04 -0400
Subject: [vtk-developers] Speeding up `import vtk`
Message-ID: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>

Folks,

This is in reference to this: https://gitlab.kitware.com/vtk/vtk/issues/16780

`import vtk` is slow because it imports all of VTK. It isn't the best
practice, and has no workaround -- given the current implementation
where all the modules are imported in vtk/__init__.py itself.

I have an MR in progress that addresses this issue:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1921

This MR does the following:
* vtk/__init__.py no longer imports all of VTK.
* vtk/all.py is a new module that imports all of VTK.

This does break old scripts, but provides an easy workaround. For
users who want to keep previous behavior, they can simply do the
following:

   from vtk import all as vtk

Thoughts? If this looks reasonable to everyone, I'll update the MR to
fix all tests accordingly.

Thanks
Utkarsh

From david.gobbi at gmail.com  Thu Sep  8 13:14:21 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 11:14:21 -0600
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
Message-ID: <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>

Hi Utkarsh,

As usual, I'm a stickler for backwards compatibility and would rather go in
the other direction,

  import vtkminimal as vtk

 - David

On Thu, Sep 8, 2016 at 10:55 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Folks,
>
> This is in reference to this: https://gitlab.kitware.com/
> vtk/vtk/issues/16780
>
> `import vtk` is slow because it imports all of VTK. It isn't the best
> practice, and has no workaround -- given the current implementation
> where all the modules are imported in vtk/__init__.py itself.
>
> I have an MR in progress that addresses this issue:
> https://gitlab.kitware.com/vtk/vtk/merge_requests/1921
>
> This MR does the following:
> * vtk/__init__.py no longer imports all of VTK.
> * vtk/all.py is a new module that imports all of VTK.
>
> This does break old scripts, but provides an easy workaround. For
> users who want to keep previous behavior, they can simply do the
> following:
>
>    from vtk import all as vtk
>
> Thoughts? If this looks reasonable to everyone, I'll update the MR to
> fix all tests accordingly.
>
> Thanks
> Utkarsh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/7f0ffafd/attachment.html>

From utkarsh.ayachit at kitware.com  Thu Sep  8 13:24:08 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 8 Sep 2016 13:24:08 -0400
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
 <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
Message-ID: <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>

The problem with that is it will have to be an entirely new package.
Further complication, this package cannot use any of *.py files for
VTK modules or others from the vtk package since as soon as it does
that vtk/__init__.py will import everything. So we'll need to
duplicate all the *.py files too.

On Thu, Sep 8, 2016 at 1:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Utkarsh,
>
> As usual, I'm a stickler for backwards compatibility and would rather go in
> the other direction,
>
>   import vtkminimal as vtk
>
>  - David
>
>
> On Thu, Sep 8, 2016 at 10:55 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>>
>> Folks,
>>
>> This is in reference to this:
>> https://gitlab.kitware.com/vtk/vtk/issues/16780
>>
>> `import vtk` is slow because it imports all of VTK. It isn't the best
>> practice, and has no workaround -- given the current implementation
>> where all the modules are imported in vtk/__init__.py itself.
>>
>> I have an MR in progress that addresses this issue:
>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1921
>>
>> This MR does the following:
>> * vtk/__init__.py no longer imports all of VTK.
>> * vtk/all.py is a new module that imports all of VTK.
>>
>> This does break old scripts, but provides an easy workaround. For
>> users who want to keep previous behavior, they can simply do the
>> following:
>>
>>    from vtk import all as vtk
>>
>> Thoughts? If this looks reasonable to everyone, I'll update the MR to
>> fix all tests accordingly.
>>
>> Thanks
>> Utkarsh

From david.gobbi at gmail.com  Thu Sep  8 13:39:07 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 11:39:07 -0600
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
 <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
 <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>
Message-ID: <CANwS1=FvUb7796qzBsSTAmG2OyubHJycMBo+92-xpOAEEn9TvQ@mail.gmail.com>

There could be a way to change the behavior of "import vtk", e.g.

import vtk_settings
vtk_settings.modules = [ ... ] # whitelist of desired modules?
import vtk

The .py files for the VTK modules are actually a bit silly, since they just
waste time moving classes from the .pyd module to the .py module.  We
should build vtkCommonCore.pyd directly (instead of building
vtkCommonCorePython.pyd).

 - David


On Thu, Sep 8, 2016 at 11:24 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> The problem with that is it will have to be an entirely new package.
> Further complication, this package cannot use any of *.py files for
> VTK modules or others from the vtk package since as soon as it does
> that vtk/__init__.py will import everything. So we'll need to
> duplicate all the *.py files too.
>
> On Thu, Sep 8, 2016 at 1:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> > Hi Utkarsh,
> >
> > As usual, I'm a stickler for backwards compatibility and would rather go
> in
> > the other direction,
> >
> >   import vtkminimal as vtk
> >
> >  - David
> >
> >
> > On Thu, Sep 8, 2016 at 10:55 AM, Utkarsh Ayachit
> > <utkarsh.ayachit at kitware.com> wrote:
> >>
> >> Folks,
> >>
> >> This is in reference to this:
> >> https://gitlab.kitware.com/vtk/vtk/issues/16780
> >>
> >> `import vtk` is slow because it imports all of VTK. It isn't the best
> >> practice, and has no workaround -- given the current implementation
> >> where all the modules are imported in vtk/__init__.py itself.
> >>
> >> I have an MR in progress that addresses this issue:
> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1921
> >>
> >> This MR does the following:
> >> * vtk/__init__.py no longer imports all of VTK.
> >> * vtk/all.py is a new module that imports all of VTK.
> >>
> >> This does break old scripts, but provides an easy workaround. For
> >> users who want to keep previous behavior, they can simply do the
> >> following:
> >>
> >>    from vtk import all as vtk
> >>
> >> Thoughts? If this looks reasonable to everyone, I'll update the MR to
> >> fix all tests accordingly.
> >>
> >> Thanks
> >> Utkarsh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/7ede5023/attachment-0001.html>

From matt.mccormick at kitware.com  Thu Sep  8 13:45:04 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 8 Sep 2016 13:45:04 -0400
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CANwS1=FvUb7796qzBsSTAmG2OyubHJycMBo+92-xpOAEEn9TvQ@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
 <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
 <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>
 <CANwS1=FvUb7796qzBsSTAmG2OyubHJycMBo+92-xpOAEEn9TvQ@mail.gmail.com>
Message-ID: <CALzTN-S7e5JMcEJ5SppbHhjkiUTTc127u3+jyPfb_QCds1W_-Q@mail.gmail.com>

In ITK, we use lazy loading. When a class is requested, its module is
loaded. When a module is loaded, all the dependent modules are loaded
(the module dependencies are exported from the build system). This
greatly reduces import times. It will be released in ITK 4.10.1. The
source tree has the details :-)

HTH,
Matt

On Thu, Sep 8, 2016 at 1:39 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> There could be a way to change the behavior of "import vtk", e.g.
>
> import vtk_settings
> vtk_settings.modules = [ ... ] # whitelist of desired modules?
> import vtk
>
> The .py files for the VTK modules are actually a bit silly, since they just
> waste time moving classes from the .pyd module to the .py module.  We should
> build vtkCommonCore.pyd directly (instead of building
> vtkCommonCorePython.pyd).
>
>  - David
>
>
> On Thu, Sep 8, 2016 at 11:24 AM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>>
>> The problem with that is it will have to be an entirely new package.
>> Further complication, this package cannot use any of *.py files for
>> VTK modules or others from the vtk package since as soon as it does
>> that vtk/__init__.py will import everything. So we'll need to
>> duplicate all the *.py files too.
>>
>> On Thu, Sep 8, 2016 at 1:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> > Hi Utkarsh,
>> >
>> > As usual, I'm a stickler for backwards compatibility and would rather go
>> > in
>> > the other direction,
>> >
>> >   import vtkminimal as vtk
>> >
>> >  - David
>> >
>> >
>> > On Thu, Sep 8, 2016 at 10:55 AM, Utkarsh Ayachit
>> > <utkarsh.ayachit at kitware.com> wrote:
>> >>
>> >> Folks,
>> >>
>> >> This is in reference to this:
>> >> https://gitlab.kitware.com/vtk/vtk/issues/16780
>> >>
>> >> `import vtk` is slow because it imports all of VTK. It isn't the best
>> >> practice, and has no workaround -- given the current implementation
>> >> where all the modules are imported in vtk/__init__.py itself.
>> >>
>> >> I have an MR in progress that addresses this issue:
>> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1921
>> >>
>> >> This MR does the following:
>> >> * vtk/__init__.py no longer imports all of VTK.
>> >> * vtk/all.py is a new module that imports all of VTK.
>> >>
>> >> This does break old scripts, but provides an easy workaround. For
>> >> users who want to keep previous behavior, they can simply do the
>> >> following:
>> >>
>> >>    from vtk import all as vtk
>> >>
>> >> Thoughts? If this looks reasonable to everyone, I'll update the MR to
>> >> fix all tests accordingly.
>> >>
>> >> Thanks
>> >> Utkarsh
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From bob.obara at kitware.com  Thu Sep  8 13:46:21 2016
From: bob.obara at kitware.com (Bob Obara)
Date: Thu, 8 Sep 2016 13:46:21 -0400
Subject: [vtk-developers] Streaming data from vtkMatrix4x4 and vtkMatrix3x3
Message-ID: <73CFC9C8-6459-481E-845A-1852020B9685@kitware.com>

Hi David,

I?ve been meaning to ask you about the depreciation of [] operator in both classes and and the comment not to use the public Element data member in the 4x4 class).  How are you suppose to be able to stream the data out of the matrix with these interfaces removed?  Obviously you can you the DeepCopy methods to ?stream? data into them.

Thanks in advance for your time and help!

Bob
 
Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/db061e96/attachment.html>

From david.gobbi at gmail.com  Thu Sep  8 13:59:53 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 11:59:53 -0600
Subject: [vtk-developers] Streaming data from vtkMatrix4x4 and
	vtkMatrix3x3
In-Reply-To: <73CFC9C8-6459-481E-845A-1852020B9685@kitware.com>
References: <73CFC9C8-6459-481E-845A-1852020B9685@kitware.com>
Message-ID: <CANwS1=HKnE1v2FPi7Q-VpG-dy5MTvxn3PRBw6ZuTRKou+3F=LA@mail.gmail.com>

Hi Bob,

I use a DeepCopy to stream in both directions:

vtkNew<vtkMatrix4x4> matrix;
double elements[16];
// stream from matrix to POD pointer
vtkMatrix4x4::DeepCopy(elements, matrix);
// stream from POD pointer to matrix
matrix->DeepCopy(elements);

 - David

On Thu, Sep 8, 2016 at 11:46 AM, Bob Obara <bob.obara at kitware.com> wrote:

> Hi David,
>
> I?ve been meaning to ask you about the depreciation of [] operator in both
> classes and and the comment not to use the public Element data member in
> the 4x4 class).  How are you suppose to be able to stream the data out of
> the matrix with these interfaces removed?  Obviously you can you the
> DeepCopy methods to ?stream? data into them.
>
> Thanks in advance for your time and help!
>
> Bob
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/55c90e3d/attachment.html>

From bob.obara at kitware.com  Thu Sep  8 14:08:15 2016
From: bob.obara at kitware.com (Bob Obara)
Date: Thu, 8 Sep 2016 14:08:15 -0400
Subject: [vtk-developers] Streaming data from vtkMatrix4x4 and
	vtkMatrix3x3
In-Reply-To: <CANwS1=HKnE1v2FPi7Q-VpG-dy5MTvxn3PRBw6ZuTRKou+3F=LA@mail.gmail.com>
References: <73CFC9C8-6459-481E-845A-1852020B9685@kitware.com>
 <CANwS1=HKnE1v2FPi7Q-VpG-dy5MTvxn3PRBw6ZuTRKou+3F=LA@mail.gmail.com>
Message-ID: <21F89520-F736-4046-8D90-4DC45B544F96@kitware.com>

Hi David,

Thanks - what is the reason these interfaces are being deprecated?

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Sep 8, 2016, at 1:59 PMEDT, David Gobbi <david.gobbi at gmail.com> wrote:
> 
> Hi Bob,
> 
> I use a DeepCopy to stream in both directions:
> 
> vtkNew<vtkMatrix4x4> matrix;
> double elements[16];
> // stream from matrix to POD pointer
> vtkMatrix4x4::DeepCopy(elements, matrix);
> // stream from POD pointer to matrix
> matrix->DeepCopy(elements);
> 
>  - David
> 
> On Thu, Sep 8, 2016 at 11:46 AM, Bob Obara <bob.obara at kitware.com <mailto:bob.obara at kitware.com>> wrote:
> Hi David,
> 
> I?ve been meaning to ask you about the depreciation of [] operator in both classes and and the comment not to use the public Element data member in the 4x4 class).  How are you suppose to be able to stream the data out of the matrix with these interfaces removed?  Obviously you can you the DeepCopy methods to ?stream? data into them.
> 
> Thanks in advance for your time and help!
> 
> Bob
>  
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
> 
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
> 
> Phone: (518) 881- 4931 <tel:%28518%29%20881-%204931>
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/33436c95/attachment.html>

From utkarsh.ayachit at kitware.com  Thu Sep  8 14:27:48 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 8 Sep 2016 14:27:48 -0400
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CALzTN-S7e5JMcEJ5SppbHhjkiUTTc127u3+jyPfb_QCds1W_-Q@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
 <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
 <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>
 <CANwS1=FvUb7796qzBsSTAmG2OyubHJycMBo+92-xpOAEEn9TvQ@mail.gmail.com>
 <CALzTN-S7e5JMcEJ5SppbHhjkiUTTc127u3+jyPfb_QCds1W_-Q@mail.gmail.com>
Message-ID: <CADHSJjCOqoi2HNdJHG_org9_3Vg7W=OBATNmEXc2eht7M479Jw@mail.gmail.com>

@Matt, Any links to the code? I have no idea where to start looking :).

@David, I like that, that seems like a reasonable workaround and
simple enough. I don't hear anything else, I'll cook something up for
the same.


On Thu, Sep 8, 2016 at 1:45 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> In ITK, we use lazy loading. When a class is requested, its module is
> loaded. When a module is loaded, all the dependent modules are loaded
> (the module dependencies are exported from the build system). This
> greatly reduces import times. It will be released in ITK 4.10.1. The
> source tree has the details :-)
>
> HTH,
> Matt
>
> On Thu, Sep 8, 2016 at 1:39 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> There could be a way to change the behavior of "import vtk", e.g.
>>
>> import vtk_settings
>> vtk_settings.modules = [ ... ] # whitelist of desired modules?
>> import vtk
>>
>> The .py files for the VTK modules are actually a bit silly, since they just
>> waste time moving classes from the .pyd module to the .py module.  We should
>> build vtkCommonCore.pyd directly (instead of building
>> vtkCommonCorePython.pyd).
>>
>>  - David
>>
>>
>> On Thu, Sep 8, 2016 at 11:24 AM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>>>
>>> The problem with that is it will have to be an entirely new package.
>>> Further complication, this package cannot use any of *.py files for
>>> VTK modules or others from the vtk package since as soon as it does
>>> that vtk/__init__.py will import everything. So we'll need to
>>> duplicate all the *.py files too.
>>>
>>> On Thu, Sep 8, 2016 at 1:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> > Hi Utkarsh,
>>> >
>>> > As usual, I'm a stickler for backwards compatibility and would rather go
>>> > in
>>> > the other direction,
>>> >
>>> >   import vtkminimal as vtk
>>> >
>>> >  - David
>>> >
>>> >
>>> > On Thu, Sep 8, 2016 at 10:55 AM, Utkarsh Ayachit
>>> > <utkarsh.ayachit at kitware.com> wrote:
>>> >>
>>> >> Folks,
>>> >>
>>> >> This is in reference to this:
>>> >> https://gitlab.kitware.com/vtk/vtk/issues/16780
>>> >>
>>> >> `import vtk` is slow because it imports all of VTK. It isn't the best
>>> >> practice, and has no workaround -- given the current implementation
>>> >> where all the modules are imported in vtk/__init__.py itself.
>>> >>
>>> >> I have an MR in progress that addresses this issue:
>>> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/1921
>>> >>
>>> >> This MR does the following:
>>> >> * vtk/__init__.py no longer imports all of VTK.
>>> >> * vtk/all.py is a new module that imports all of VTK.
>>> >>
>>> >> This does break old scripts, but provides an easy workaround. For
>>> >> users who want to keep previous behavior, they can simply do the
>>> >> following:
>>> >>
>>> >>    from vtk import all as vtk
>>> >>
>>> >> Thoughts? If this looks reasonable to everyone, I'll update the MR to
>>> >> fix all tests accordingly.
>>> >>
>>> >> Thanks
>>> >> Utkarsh
>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>

From david.gobbi at gmail.com  Thu Sep  8 14:35:19 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 8 Sep 2016 12:35:19 -0600
Subject: [vtk-developers] Streaming data from vtkMatrix4x4 and
	vtkMatrix3x3
In-Reply-To: <21F89520-F736-4046-8D90-4DC45B544F96@kitware.com>
References: <73CFC9C8-6459-481E-845A-1852020B9685@kitware.com>
 <CANwS1=HKnE1v2FPi7Q-VpG-dy5MTvxn3PRBw6ZuTRKou+3F=LA@mail.gmail.com>
 <21F89520-F736-4046-8D90-4DC45B544F96@kitware.com>
Message-ID: <CANwS1=GWMvAWAqf3raYTorehU4RZJBNZv6HBQwTNQE-tHsRv8g@mail.gmail.com>

My own opinion is that the use of these operators results in obfuscation.
They were added to VTK waay back when VTK objects were passed by reference
rather than by pointer, and back then one could write "matrix[i][j]".  In
comparison, (*matrix)[i][j] is hard to read.  When I deprecated operator[],
only one class in all of VTK was using it, so it definitely wasn't winning
any popularity contests :)

 - David


On Thu, Sep 8, 2016 at 12:08 PM, Bob Obara <bob.obara at kitware.com> wrote:

> Hi David,
>
> Thanks - what is the reason these interfaces are being deprecated?
>
> Bob
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931
>
>
>
>
> On Sep 8, 2016, at 1:59 PMEDT, David Gobbi <david.gobbi at gmail.com> wrote:
>
> Hi Bob,
>
> I use a DeepCopy to stream in both directions:
>
> vtkNew<vtkMatrix4x4> matrix;
> double elements[16];
> // stream from matrix to POD pointer
> vtkMatrix4x4::DeepCopy(elements, matrix);
> // stream from POD pointer to matrix
> matrix->DeepCopy(elements);
>
>  - David
>
> On Thu, Sep 8, 2016 at 11:46 AM, Bob Obara <bob.obara at kitware.com> wrote:
>
>> Hi David,
>>
>> I?ve been meaning to ask you about the depreciation of [] operator in
>> both classes and and the comment not to use the public Element data member
>> in the 4x4 class).  How are you suppose to be able to stream the data out
>> of the matrix with these interfaces removed?  Obviously you can you the
>> DeepCopy methods to ?stream? data into them.
>>
>> Thanks in advance for your time and help!
>>
>> Bob
>>
>> Robert M. O'Bara, MEng.
>> Assistant Director of Scientific Computing
>>
>> Kitware Inc.
>> 28 Corporate Drive
>> Suite 101
>> Clifton Park, NY 12065
>>
>> Phone: (518) 881- 4931
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160908/6033c484/attachment.html>

From matt.mccormick at kitware.com  Thu Sep  8 15:45:51 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 8 Sep 2016 15:45:51 -0400
Subject: [vtk-developers] Speeding up `import vtk`
In-Reply-To: <CADHSJjCOqoi2HNdJHG_org9_3Vg7W=OBATNmEXc2eht7M479Jw@mail.gmail.com>
References: <CADHSJjBifgd9nbkeoAkbb=jZZ0ZHHVw4THFsqqdYJFmQvFGtGg@mail.gmail.com>
 <CANwS1=EHrCx=w8gW7HvS3RZDx1Bjz8N5uhFHgQFw58Fj_UvaeA@mail.gmail.com>
 <CADHSJjA7ud5M7dCBjNOj7C+eT4W_BCBWCnYQVJ6QX+Jusqe6gQ@mail.gmail.com>
 <CANwS1=FvUb7796qzBsSTAmG2OyubHJycMBo+92-xpOAEEn9TvQ@mail.gmail.com>
 <CALzTN-S7e5JMcEJ5SppbHhjkiUTTc127u3+jyPfb_QCds1W_-Q@mail.gmail.com>
 <CADHSJjCOqoi2HNdJHG_org9_3Vg7W=OBATNmEXc2eht7M479Jw@mail.gmail.com>
Message-ID: <CALzTN-TkZDrbpoAV8=XN74RRarEkjr8WU4pFL+DMHRJWa1w_tg@mail.gmail.com>

On Thu, Sep 8, 2016 at 2:27 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> @Matt, Any links to the code? I have no idea where to start looking :).

There are different components, but here are some starting points:

  https://github.com/InsightSoftwareConsortium/ITK/blob/22cd834098516f0afbc669a10133463d9f7c890d/Wrapping/Generators/Python/itkLazy.py#L20-L48

  https://github.com/InsightSoftwareConsortium/ITK/blob/22cd834098516f0afbc669a10133463d9f7c890d/Wrapping/Generators/Python/itkBase.py#L34-L46

From utkarsh.ayachit at kitware.com  Thu Sep  8 16:47:18 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 8 Sep 2016 16:47:18 -0400
Subject: [vtk-developers] Anyone looked at GLFW?
Message-ID: <CADHSJjCq4BPfVe63EwyTa7Y0s9pm97szhS-QTZC7OPmHBgsvcA@mail.gmail.com>

Folks,

Has anyone looked at GLFW?

http://www.glfw.org/

Seems like a nice way of cleaning up the Window system code from VTK.

Utkarsh

From david.lonie at kitware.com  Thu Sep  8 17:42:21 2016
From: david.lonie at kitware.com (David Lonie)
Date: Thu, 8 Sep 2016 17:42:21 -0400
Subject: [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
Message-ID: <CA+=e1os0EqPbgy_pdpHzAGJgUvE2qiYnQ0KprkZ6APRrcvMrJA@mail.gmail.com>

Hi all,

We've been seeing some issues surrounding the use of vtkDebugLeaks and
template classes lately. The main problem stems from the difficulties
of ensuring that ::GetClassName() returns a unique string for
different instantiations of a templated object. This is important to
ensure that things like SafeDownCast work correctly.

At the moment, ::GetClassName() returns typeid(this).name() for
templated types, which is typically very different from the string
passed into vtkObjectFactory::ConstructInstance(...) by the object
factory macros used to implement the ::New() methods.

Right now we jump through some hoops to try to make sure that
vtkDebugLeaks::ConstructClass is called with the ::GetClassName()
string, since that is used when vtkObjectBase::UnregisterInternal
removes an object from the leak tracker. But we've missed some spots
and there are quite a few classes that don't bother with the macros,
and thus have custom implementations of ::New() that need to
explicitly register themselves with DebugLeaks. It's getting messy and
problematic trying to keep all of this consistent.

I propose that we simplify DebugLeaks to make the registration happen
automatically. I see a couple of ways to do this:

1) Just track the objects directly by registering their addresses in
vtkObjectBase's constructor. This would increase the memory footprint
of vtkDebugLeaks, but I think that's not a huge issue since
vtkDebugLeaks is a testing/development tool that isn't used in
production AFAIK. This would also allow a more detailed printout of
the leaked objects since we could call Print() on them.

2) Continue registering name strings, but do so from a
vtkObjectBase::InternalInitialize() (or similar) method that calls
vtkDebugLeaks::ConstructClass(this->GetClassName(). This would still
need to be called explicitly in custom ::New() implementations, but it
would be easier to maintain, update, and keep consistent/correct
thanks to the encapsulation to a single method.

Note that we can't just call
vtkDebugLeaks::ConstructClass(this->GetClassName()) from
vtkObjectBase's constructor due to how virtual methods in constructors
work. ::GetClassName() will always return "vtkObjectBase" when called
from vtkObjectBase's constructor.

Any thoughts/objections/suggestions?

Dave

From kmorel at sandia.gov  Thu Sep  8 17:53:04 2016
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Thu, 8 Sep 2016 21:53:04 +0000
Subject: [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
Message-ID: <739e39dac1014adcbbfdd2707c386cf6@ES08AMSNLNT.srn.sandia.gov>

Why not use typeid(this) instead of GetClassName? As long as this has one virtual function, I believe typeid will give the id for the base class.

-Ken

-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Lonie
Sent: Thursday, September 8, 2016 3:42 PM
To: VTK Developers <vtk-developers at vtk.org>
Subject: [EXTERNAL] [vtk-developers] Proposal: Simplify vtkDebugLeaks registration

Hi all,

We've been seeing some issues surrounding the use of vtkDebugLeaks and template classes lately. The main problem stems from the difficulties of ensuring that ::GetClassName() returns a unique string for different instantiations of a templated object. This is important to ensure that things like SafeDownCast work correctly.

At the moment, ::GetClassName() returns typeid(this).name() for templated types, which is typically very different from the string passed into vtkObjectFactory::ConstructInstance(...) by the object factory macros used to implement the ::New() methods.

Right now we jump through some hoops to try to make sure that vtkDebugLeaks::ConstructClass is called with the ::GetClassName() string, since that is used when vtkObjectBase::UnregisterInternal removes an object from the leak tracker. But we've missed some spots and there are quite a few classes that don't bother with the macros, and thus have custom implementations of ::New() that need to explicitly register themselves with DebugLeaks. It's getting messy and problematic trying to keep all of this consistent.

I propose that we simplify DebugLeaks to make the registration happen automatically. I see a couple of ways to do this:

1) Just track the objects directly by registering their addresses in vtkObjectBase's constructor. This would increase the memory footprint of vtkDebugLeaks, but I think that's not a huge issue since vtkDebugLeaks is a testing/development tool that isn't used in production AFAIK. This would also allow a more detailed printout of the leaked objects since we could call Print() on them.

2) Continue registering name strings, but do so from a
vtkObjectBase::InternalInitialize() (or similar) method that calls vtkDebugLeaks::ConstructClass(this->GetClassName(). This would still need to be called explicitly in custom ::New() implementations, but it would be easier to maintain, update, and keep consistent/correct thanks to the encapsulation to a single method.

Note that we can't just call
vtkDebugLeaks::ConstructClass(this->GetClassName()) from vtkObjectBase's constructor due to how virtual methods in constructors work. ::GetClassName() will always return "vtkObjectBase" when called from vtkObjectBase's constructor.

Any thoughts/objections/suggestions?

Dave
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


From DLRdave at aol.com  Thu Sep  8 18:11:37 2016
From: DLRdave at aol.com (David Cole)
Date: Thu, 8 Sep 2016 18:11:37 -0400
Subject: [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
In-Reply-To: <739e39dac1014adcbbfdd2707c386cf6@ES08AMSNLNT.srn.sandia.gov>
References: <739e39dac1014adcbbfdd2707c386cf6@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <CAKME8fEnrn0AXCi9f-jSEL79eD0OFa1sySuuozJuNuFMuFmf_g@mail.gmail.com>

A few comments:

That should be typeid(*this), and I'm uncertain if that works in the
context of a base class constructor before the derived class's
constructor is called. Does it? Doesn't seem like it should...

If you do end up tracking every instance, and printing them all at
leak time, perhaps have a sane way of only printing **some** of them.
Usually, when I end up with a leak, it's connected to a vast network
of objects, and they all leak, with hundreds, if not thousands of
objects leaking.

Also, if you end up tracking every instance, it would be great to have
an API to the leaks manager to count and iterate all the outstanding
instances.


2 cents,
David C.



On Thu, Sep 8, 2016 at 5:53 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> Why not use typeid(this) instead of GetClassName? As long as this has one virtual function, I believe typeid will give the id for the base class.
>
> -Ken
>
> -----Original Message-----
> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Lonie
> Sent: Thursday, September 8, 2016 3:42 PM
> To: VTK Developers <vtk-developers at vtk.org>
> Subject: [EXTERNAL] [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
>
> Hi all,
>
> We've been seeing some issues surrounding the use of vtkDebugLeaks and template classes lately. The main problem stems from the difficulties of ensuring that ::GetClassName() returns a unique string for different instantiations of a templated object. This is important to ensure that things like SafeDownCast work correctly.
>
> At the moment, ::GetClassName() returns typeid(this).name() for templated types, which is typically very different from the string passed into vtkObjectFactory::ConstructInstance(...) by the object factory macros used to implement the ::New() methods.
>
> Right now we jump through some hoops to try to make sure that vtkDebugLeaks::ConstructClass is called with the ::GetClassName() string, since that is used when vtkObjectBase::UnregisterInternal removes an object from the leak tracker. But we've missed some spots and there are quite a few classes that don't bother with the macros, and thus have custom implementations of ::New() that need to explicitly register themselves with DebugLeaks. It's getting messy and problematic trying to keep all of this consistent.
>
> I propose that we simplify DebugLeaks to make the registration happen automatically. I see a couple of ways to do this:
>
> 1) Just track the objects directly by registering their addresses in vtkObjectBase's constructor. This would increase the memory footprint of vtkDebugLeaks, but I think that's not a huge issue since vtkDebugLeaks is a testing/development tool that isn't used in production AFAIK. This would also allow a more detailed printout of the leaked objects since we could call Print() on them.
>
> 2) Continue registering name strings, but do so from a
> vtkObjectBase::InternalInitialize() (or similar) method that calls vtkDebugLeaks::ConstructClass(this->GetClassName(). This would still need to be called explicitly in custom ::New() implementations, but it would be easier to maintain, update, and keep consistent/correct thanks to the encapsulation to a single method.
>
> Note that we can't just call
> vtkDebugLeaks::ConstructClass(this->GetClassName()) from vtkObjectBase's constructor due to how virtual methods in constructors work. ::GetClassName() will always return "vtkObjectBase" when called from vtkObjectBase's constructor.
>
> Any thoughts/objections/suggestions?
>
> Dave
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From mathieu.westphal at kitware.com  Fri Sep  9 03:22:05 2016
From: mathieu.westphal at kitware.com (Mathieu Westphal)
Date: Fri, 9 Sep 2016 09:22:05 +0200
Subject: [vtk-developers] Anyone looked at GLFW?
In-Reply-To: <CADHSJjCq4BPfVe63EwyTa7Y0s9pm97szhS-QTZC7OPmHBgsvcA@mail.gmail.com>
References: <CADHSJjCq4BPfVe63EwyTa7Y0s9pm97szhS-QTZC7OPmHBgsvcA@mail.gmail.com>
Message-ID: <CAC2t4UQZ0NbL8njdja2wyyvtc0+bD9cv37qRxV=wnUTAGp09YA@mail.gmail.com>

Never used, but heard only good things first hand.

Mathieu
On Thu, Sep 8, 2016 at 10:47 PM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Folks,
>
> Has anyone looked at GLFW?
>
> http://www.glfw.org/
>
> Seems like a nice way of cleaning up the Window system code from VTK.
>
> Utkarsh
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/d2878600/attachment.html>

From dave.demarle at kitware.com  Fri Sep  9 07:05:34 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 9 Sep 2016 07:05:34 -0400
Subject: [vtk-developers] MR to reindent VTK's braces
In-Reply-To: <CANjZAi89cBN8jSDYXufRiP__75wZ3nsExL7uKQpm2pBPqAO7tg@mail.gmail.com>
References: <CANwS1=FuX7Rh45GhoRFcs7qOFAJCqzLawFNsaebmcDz1nWg7RQ@mail.gmail.com>
 <CANjZAi-OnKCRpLGzihpheyze7hR17iJUkdhbqqzqFW7CQmtJwQ@mail.gmail.com>
 <CALSpCT3PEWb2wTMFXXQdbq_DrjO0s6DtCqM-eF-3LormOMR2Xg@mail.gmail.com>
 <20160907201957.GA5337@megas.kitware.com>
 <CANjZAi9SkkQYkx+kT6hf+L1NmaQx4EjhSwpdmJbkrSWNv=+dLg@mail.gmail.com>
 <20160908130606.GA13993@megas.kitware.com>
 <CAKME8fF1S=mrZPqW5BEhF3MTm6xVWkaHn4S7UasJKu-+HVeP5g@mail.gmail.com>
 <CANjZAi8Ng74KkXyN-CHCK6SkfRcRs26ePH_oj7WXnvrvPqrVww@mail.gmail.com>
 <CAE32kpVqvqSOv+k8adQ6t-=OO+gT0d0rxceiSJWfrEKnn8tDvw@mail.gmail.com>
 <CANwS1=EhkCdBZQUc_vdXQG=KuRQ98590g+QZytq9V=io2waUDw@mail.gmail.com>
 <CAKME8fGD1A2dqCTdvdaUNpLKYXft2BU4py43B2F_M03eg6irgQ@mail.gmail.com>
 <CAE32kpWdabT7Mu5cxH6M8R5rvQAiscGjs5UVYDVB+CGrkXdcsQ@mail.gmail.com>
 <CANwS1=Gbe=TLXcgz-vWob_1ZAVFJ7tOyS7WqrNu5-9DAdP8cCw@mail.gmail.com>
 <CANjZAi89cBN8jSDYXufRiP__75wZ3nsExL7uKQpm2pBPqAO7tg@mail.gmail.com>
Message-ID: <CANjZAi8Y4S=MB3pBRVVxCs+PJsqzJtP7GH9NrJx4H0KuTgvjNg@mail.gmail.com>

So as long as this approach checks out alright:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1932

Then I'm fine with merging both things in the next couple of days and
branching for 7.1 afterward.

My misgivings about whether these sweeping format changes belong be in a
minor release are moot because of the mtime,  VTK_OVERRIDE and
VTK_DELETE_FUNCTION changes will already be present.

Merging before the branch will certainly make patches to both 7.1 and 8.0
easier to boot.





David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Sep 8, 2016 at 12:10 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> To first approximation this doesn't appear hard to do:
>
> perl Utilities/Doxygen/doc_header2doxygen.pl  --to ~/tmp $VTKSRC
> cp -r ~/tmp $VTKSRC
>
> There is probably more to it than that. I'll poke around now.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Thu, Sep 8, 2016 at 11:04 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Is anyone working on the Doxygen changes, though?  Unless we have some
>> idea of when it's going to be done, it shouldn't be influencing decisions
>> about other merges.
>>
>> On Thu, Sep 8, 2016 at 8:49 AM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> I agree with Dave's (DeMarle) argument that we should do this at the
>>> same time as the Doxygen changes. It would be annoying to have two merge
>>> barriers in a manner of a few months.
>>>
>>> -berk
>>>
>>> On Thu, Sep 8, 2016 at 10:42 AM, David Cole <DLRdave at aol.com> wrote:
>>>
>>>> +1
>>>>
>>>> Automatic even. ;-)
>>>>
>>>> Daves on the VTK lists unite!
>>>>
>>>>
>>>>
>>>> On Thu, Sep 8, 2016 at 10:00 AM, David Gobbi <david.gobbi at gmail.com>
>>>> wrote:
>>>> > In general, I'd love to see VTK move to regularly-scheduled minor
>>>> releases
>>>> > with firm dates set months in advance :)
>>>> >
>>>> > On Thu, Sep 8, 2016 at 7:34 AM, Berk Geveci <berk.geveci at kitware.com>
>>>> wrote:
>>>> >>
>>>> >> One way or another it would be great to choose & announce a date for
>>>> >> merging this. That way, people with existing work will know when
>>>> potential
>>>> >> conflicts are coming.
>>>> >>
>>>> >> On Thu, Sep 8, 2016 at 9:29 AM, David E DeMarle <
>>>> dave.demarle at kitware.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> I want to do a release soonish only because:
>>>> >>> * 7.0.0 is getting long in the tooth and I've not found any time to
>>>> do
>>>> >>> 7.0.1
>>>> >>> * It is helpful for ParaView releases if VTK has a recent release
>>>> to work
>>>> >>> from, and PV 5.2 is expected month or so from now.
>>>> >>>
>>>> >>> Why shouldn't we do this now?
>>>> >>> * the doxygen update will also be a disruption, so we should
>>>> combine so
>>>> >>> people only go through the pain once
>>>> >>> * my vague feelings about whether this should be in a minor release
>>>> or a
>>>> >>> major release, and we know we want a major release very soon.
>>>> >>>
>>>> >>>
>>>> >>> David E DeMarle
>>>> >>> Kitware, Inc.
>>>> >>> R&D Engineer
>>>> >>> 21 Corporate Drive
>>>> >>> Clifton Park, NY 12065-8662
>>>> >>> Phone: 518-881-4909
>>>> >>>
>>>> >>> On Thu, Sep 8, 2016 at 9:10 AM, David Cole <DLRdave at aol.com> wrote:
>>>> >>>>
>>>> >>>> It would seem better to bite the bullet and do it now unless there
>>>> is
>>>> >>>> an extremely urgent deadline for 7.1......
>>>> >>>>
>>>> >>>> D
>>>> >>>>
>>>> >>>>
>>>> >>>> On Thu, Sep 8, 2016 at 9:06 AM, Ben Boeckel <
>>>> ben.boeckel at kitware.com>
>>>> >>>> wrote:
>>>> >>>> > On Thu, Sep 08, 2016 at 09:02:09 -0400, David E DeMarle wrote:
>>>> >>>> >> How about after 7.1 final then.
>>>> >>>> >>
>>>> >>>> >> That and the reworking of doxygen will disrupt pretty much
>>>> everyone's
>>>> >>>> >> existing branches, so better to come out first as part of 8.0.
>>>> >>>> >
>>>> >>>> > No, because any branch which is meant for 7.1 then needs two
>>>> versions:
>>>> >>>> > one for master (post-cleanup) and another for 7.1 itself
>>>> >>>> > (pre-cleanup).
>>>> >>>> >
>>>> >>>> > --Ben
>>>> >>>> > _______________________________________________
>>>> >>>> > Powered by www.kitware.com
>>>> >>>> >
>>>> >>>> > Visit other Kitware open-source projects at
>>>> >>>> > http://www.kitware.com/opensource/opensource.html
>>>> >>>> >
>>>> >>>> > Search the list archives at:
>>>> >>>> > http://markmail.org/search/?q=vtk-developers
>>>> >>>> >
>>>> >>>> > Follow this link to subscribe/unsubscribe:
>>>> >>>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> >>>> >
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Powered by www.kitware.com
>>>> >>>
>>>> >>> Visit other Kitware open-source projects at
>>>> >>> http://www.kitware.com/opensource/opensource.html
>>>> >>>
>>>> >>> Search the list archives at: http://markmail.org/search/?q=
>>>> vtk-developers
>>>> >>>
>>>> >>> Follow this link to subscribe/unsubscribe:
>>>> >>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/cbd29fe1/attachment.html>

From david.lonie at kitware.com  Fri Sep  9 09:27:04 2016
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 9 Sep 2016 09:27:04 -0400
Subject: [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
In-Reply-To: <CAKME8fEnrn0AXCi9f-jSEL79eD0OFa1sySuuozJuNuFMuFmf_g@mail.gmail.com>
References: <739e39dac1014adcbbfdd2707c386cf6@ES08AMSNLNT.srn.sandia.gov>
 <CAKME8fEnrn0AXCi9f-jSEL79eD0OFa1sySuuozJuNuFMuFmf_g@mail.gmail.com>
Message-ID: <CA+=e1ot=zViKY1uCWV=CYDTaxRq6SxLbMrN1nFjOir30dU8-Gw@mail.gmail.com>

On Thu, Sep 8, 2016 at 6:11 PM, David Cole <DLRdave at aol.com> wrote:
> A few comments:
>
> That should be typeid(*this), and I'm uncertain if that works in the
> context of a base class constructor before the derived class's
> constructor is called. Does it? Doesn't seem like it should...

typeid will always resolve to the "current" class when called from a
constructor/destructor.

For science: http://codepad.org/WWweG8hk

#include <iostream>

struct Base
{
  Base() { std::cout << typeid(*this).name() << std::endl; }
  virtual ~Base() { std::cout << "~" << typeid(*this).name() << std::endl; }

  void Init() const { std::cout << typeid(*this).name() << std::endl; }
};

struct Derived : public Base
{
};

int main()
{
  Derived d;
  d.Init();
  return 0;
}

Output:
4Base
7Derived
~4Base

The second suggestion in my first email would move the construction
logic to something like the Init() method in that example, which
resolves properly to the Derived class.

> If you do end up tracking every instance, and printing them all at
> leak time, perhaps have a sane way of only printing **some** of them.
> Usually, when I end up with a leak, it's connected to a vast network
> of objects, and they all leak, with hundreds, if not thousands of
> objects leaking.

I agree, digging through the ::Print() output for 100's of objects
would not be useful for most cases! My plan for the object-based
report would be to iterate through the leaked objects, collect
classnames/counts, and print the summary just like it does now by
default. Optionally it could check an environment variable to print a
complete output with object details.

> Also, if you end up tracking every instance, it would be great to have
> an API to the leaks manager to count and iterate all the outstanding
> instances.

That would certainly be useful. Something like void
vtkDebugLeaks::GetCurrentObjects(vtkObjectBaseCollection *col) should
do the trick.

Personally I'm leaning towards the second option (collect strings but
use a centralized vtkObjectBase::InternalInit() method) as it's less
intrusive/less work.

Dave

From kmorel at sandia.gov  Fri Sep  9 16:21:32 2016
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Fri, 9 Sep 2016 20:21:32 +0000
Subject: [vtk-developers] Anyone looked at GLFW?
Message-ID: <3F2FCDF4-20FC-4CA7-83A1-E5BC3572774D@sandia.gov>

I?ve used it a few times and have been pretty happy with it. Probably the bigger issue is that it adds a library dependence to VTK, and GLFW is not commonly installed on any system.

-Ken


From: vtk-developers <vtk-developers-bounces at vtk.org> on behalf of Mathieu Westphal <mathieu.westphal at kitware.com>
Date: Friday, September 9, 2016 at 1:22 AM
To: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
Cc: "vtk-developers at vtk.org" <vtk-developers at vtk.org>
Subject: [EXTERNAL] Re: [vtk-developers] Anyone looked at GLFW?

Never used, but heard only good things first hand.
Mathieu
On Thu, Sep 8, 2016 at 10:47 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com<mailto:utkarsh.ayachit at kitware.com>> wrote:
Folks,

Has anyone looked at GLFW?

http://www.glfw.org/

Seems like a nice way of cleaning up the Window system code from VTK.

Utkarsh
_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/8626469d/attachment.html>

From milefn at rpi.edu  Fri Sep  9 17:47:10 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 9 Sep 2016 21:47:10 +0000
Subject: [vtk-developers] Why is BuildShaders() continuously being called?
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>

Under what conditions are shaders actually rebuilt? This seems to be the source of my performance issues and I need to know how to avoid this. The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that they get rebuilt when an object gets modified, is this true?

Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/d295f673/attachment.html>

From ken.martin at kitware.com  Fri Sep  9 17:58:03 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 9 Sep 2016 17:58:03 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
Message-ID: <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>

When  GetNeedToRebuildShaders returns true. Which roughly is

  if (cellBO.Program == 0 ||
      cellBO.ShaderSourceTime < this->GetMTime() ||
      cellBO.ShaderSourceTime < actor->GetMTime() ||
      cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
      cellBO.ShaderSourceTime < this->SelectionStateChanged ||
      cellBO.ShaderSourceTime < renderPassMTime ||
      cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
    {
    return true;
    }

So if the main points are if you are modifying the actor, mapper, or your
data. If one of those is being modified every frame then let me know the
use case and we can see if the current test is being too aggressive etc.

Thanks
Ken




On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Under what conditions are shaders actually rebuilt? This seems to be the
> source of my performance issues and I need to know how to avoid this. The
> function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that
> they get rebuilt when an object gets modified, is this true?
>
> Thanks,
> Nick
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/1ff58a0f/attachment.html>

From milefn at rpi.edu  Fri Sep  9 18:20:04 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Fri, 9 Sep 2016 22:20:04 +0000
Subject: [vtk-developers] Why is BuildShaders() continuously being
 called?
In-Reply-To: <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>,
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>

Thanks Ken. I was moving a few cone sources around (about 50) with SetPosition() and I see that they called Modified() which I'm guessing changes MTime? It was mostly for debugging because I can actually get around some of this in shaders to avoid going through the rendering pipeline. But, there are times when I need to move actors in real time, so this can sometimes be a bottleneck for me.

Thanks,
Nick
________________________________
From: Ken Martin [ken.martin at kitware.com]
Sent: Friday, September 09, 2016 5:58 PM
To: Milef, Nicholas Boris
Cc: vtk-developers at vtk.org
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

When  GetNeedToRebuildShaders returns true. Which roughly is

  if (cellBO.Program == 0 ||
      cellBO.ShaderSourceTime < this->GetMTime() ||
      cellBO.ShaderSourceTime < actor->GetMTime() ||
      cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
      cellBO.ShaderSourceTime < this->SelectionStateChanged ||
      cellBO.ShaderSourceTime < renderPassMTime ||
      cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
    {
    return true;
    }

So if the main points are if you are modifying the actor, mapper, or your data. If one of those is being modified every frame then let me know the use case and we can see if the current test is being too aggressive etc.

Thanks
Ken




On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=ONPFOfU2bpzpsrcIgt2m7hhEWUJNJohZBPDsZ_BG4gPOQ7kY_tjTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
Under what conditions are shaders actually rebuilt? This seems to be the source of my performance issues and I need to know how to avoid this. The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that they get rebuilt when an object gets modified, is this true?

Thanks,
Nick

_______________________________________________
Powered by www.kitware.com<redir.aspx?REF=z0loocjZVeRvKP64EwrIgSUxd20gmnkUMWd_jmz3X9gvpbsY_tjTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<redir.aspx?REF=xjL0ZBleD_hOp6gyTWCXZg3Oa88-8VbNha3cE3QD4LwvpbsY_tjTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<redir.aspx?REF=F1wcM-MWHo04vjS2vE_PfRsGFLOBuooAfHuTJGGv_fAvpbsY_tjTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers<redir.aspx?REF=MhWBAevYNiqKNHblyp0YPuAiErwuqE4gdxAjUqqO-0YvpbsY_tjTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>





--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160909/957fc35a/attachment-0001.html>

From utkarsh.ayachit at kitware.com  Fri Sep  9 20:33:55 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Fri, 9 Sep 2016 20:33:55 -0400
Subject: [vtk-developers] Anyone looked at GLFW?
In-Reply-To: <3F2FCDF4-20FC-4CA7-83A1-E5BC3572774D@sandia.gov>
References: <3F2FCDF4-20FC-4CA7-83A1-E5BC3572774D@sandia.gov>
Message-ID: <CADHSJjC7fH3g3cyXGCSyzVu7gxjbcM3kcBAcoTH4ZBrDzXQFSQ@mail.gmail.com>

Thanks for the info. I will play with it some too. I have been
generally frustrated with VTK's window management code (latest one I
encountered --- offscreen on windows is causing segfaults) and feel we
need a cleaner alternative. If this is a clean solution, it may be
worthwhile incorporating it into VTK. It's already uses CMake as the
build system and uses the zlib/png license -- hence not an issue there
too.

On Fri, Sep 9, 2016 at 4:21 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> I?ve used it a few times and have been pretty happy with it. Probably the
> bigger issue is that it adds a library dependence to VTK, and GLFW is not
> commonly installed on any system.
>
>
>
> -Ken
>
>
>
>
>
> From: vtk-developers <vtk-developers-bounces at vtk.org> on behalf of Mathieu
> Westphal <mathieu.westphal at kitware.com>
> Date: Friday, September 9, 2016 at 1:22 AM
> To: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> Cc: "vtk-developers at vtk.org" <vtk-developers at vtk.org>
> Subject: [EXTERNAL] Re: [vtk-developers] Anyone looked at GLFW?
>
>
>
> Never used, but heard only good things first hand.
>
> Mathieu
>
> On Thu, Sep 8, 2016 at 10:47 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>
> Folks,
>
> Has anyone looked at GLFW?
>
> http://www.glfw.org/
>
> Seems like a nice way of cleaning up the Window system code from VTK.
>
> Utkarsh
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From ken.martin at kitware.com  Mon Sep 12 09:55:43 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Mon, 12 Sep 2016 09:55:43 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
Message-ID: <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>

Thanks. I need to make that test more conservative. I'll try making a topic
soon to update it. Probably what it needs is

(actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
(actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||

as opposed to the

actor->GetMTime() > ...

line

Thanks
Ken

On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Thanks Ken. I was moving a few cone sources around (about 50) with
> SetPosition() and I see that they called Modified() which I'm guessing
> changes MTime? It was mostly for debugging because I can actually get
> around some of this in shaders to avoid going through the rendering
> pipeline. But, there are times when I need to move actors in real time, so
> this can sometimes be a bottleneck for me.
>
> Thanks,
> Nick
> ------------------------------
> *From:* Ken Martin [ken.martin at kitware.com]
> *Sent:* Friday, September 09, 2016 5:58 PM
> *To:* Milef, Nicholas Boris
> *Cc:* vtk-developers at vtk.org
> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
> called?
>
> When  GetNeedToRebuildShaders returns true. Which roughly is
>
>   if (cellBO.Program == 0 ||
>       cellBO.ShaderSourceTime < this->GetMTime() ||
>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>       cellBO.ShaderSourceTime < renderPassMTime ||
>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>     {
>     return true;
>     }
>
> So if the main points are if you are modifying the actor, mapper, or your
> data. If one of those is being modified every frame then let me know the
> use case and we can see if the current test is being too aggressive etc.
>
> Thanks
> Ken
>
>
>
>
> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
> <http://redir.aspx?REF=ONPFOfU2bpzpsrcIgt2m7hhEWUJNJohZBPDsZ_BG4gPOQ7kY_tjTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
> > wrote:
>
>> Under what conditions are shaders actually rebuilt? This seems to be the
>> source of my performance issues and I need to know how to avoid this. The
>> function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that
>> they get rebuilt when an object gets modified, is this true?
>>
>> Thanks,
>> Nick
>>
>> _______________________________________________
>> Powered by www.kitware.com
>> <http://redir.aspx?REF=z0loocjZVeRvKP64EwrIgSUxd20gmnkUMWd_jmz3X9gvpbsY_tjTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> <http://redir.aspx?REF=xjL0ZBleD_hOp6gyTWCXZg3Oa88-8VbNha3cE3QD4LwvpbsY_tjTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>> <http://redir.aspx?REF=F1wcM-MWHo04vjS2vE_PfRsGFLOBuooAfHuTJGGv_fAvpbsY_tjTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>> <http://redir.aspx?REF=MhWBAevYNiqKNHblyp0YPuAiErwuqE4gdxAjUqqO-0YvpbsY_tjTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>
>>
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>



-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160912/ff4ebba3/attachment.html>

From ken.martin at kitware.com  Mon Sep 12 10:17:11 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Mon, 12 Sep 2016 10:17:11 -0400
Subject: [vtk-developers] dejagore may be messed up
Message-ID: <CANXz0Sb=NJPQGGDqgCKWtdK+F7Xg+95berG0Ze+Sn=k=kh6sKg@mail.gmail.com>

I just received these results on a dashboard

Invalid MIT-MAGIC-COOKIE-1 keyERROR: In
/home/kitware/buildbot-slave/vtk-dejagore-linux-shared-release_gcc_mpi_python_qt/source/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx,
line 481
vtkXOpenGLRenderWindow (0x23a04d0): bad X server connection.
DISPLAY=:0. Aborting.




-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160912/54aada78/attachment.html>

From robert.maynard at kitware.com  Mon Sep 12 13:44:45 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 12 Sep 2016 13:44:45 -0400
Subject: [vtk-developers] dejagore may be messed up
In-Reply-To: <CANXz0Sb=NJPQGGDqgCKWtdK+F7Xg+95berG0Ze+Sn=k=kh6sKg@mail.gmail.com>
References: <CANXz0Sb=NJPQGGDqgCKWtdK+F7Xg+95berG0Ze+Sn=k=kh6sKg@mail.gmail.com>
Message-ID: <CAFzjYVoVBR7mQwCGnTfEb7R9=psB8FUyyO-L7YMMpHSZiuLRjA@mail.gmail.com>

The dejagore machine was upgraded from Ubuntu 14.04 to 16.04 late last
week. During the upgrade the ability to login automatically after
reboot was broken, causing the above failure ( I believe ). I will
start working on fixing the automatic login today.

On Mon, Sep 12, 2016 at 10:17 AM, Ken Martin <ken.martin at kitware.com> wrote:
>
> I just received these results on a dashboard
>
> Invalid MIT-MAGIC-COOKIE-1 keyERROR: In
> /home/kitware/buildbot-slave/vtk-dejagore-linux-shared-release_gcc_mpi_python_qt/source/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx,
> line 481
> vtkXOpenGLRenderWindow (0x23a04d0): bad X server connection. DISPLAY=:0.
> Aborting.
>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From milefn at rpi.edu  Mon Sep 12 14:49:03 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Mon, 12 Sep 2016 18:49:03 +0000
Subject: [vtk-developers] Why is BuildShaders() continuously being
 called?
In-Reply-To: <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>,
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>

Thanks, that's very helpful! During my performance analysis, I also saw in the UpdateShader() method, updating the shader uniforms took up a lot of CPU time as well (at least 40% of the total CPU time). Is it possible to add more aggressive modification checks to this? For instance, some of the uniforms such as color may never change.

Thanks,
Nick
________________________________
From: Ken Martin [ken.martin at kitware.com]
Sent: Monday, September 12, 2016 9:55 AM
To: Milef, Nicholas Boris
Cc: vtk-developers at vtk.org
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

Thanks. I need to make that test more conservative. I'll try making a topic soon to update it. Probably what it needs is

(actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
(actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||

as opposed to the

actor->GetMTime() > ...

line

Thanks
Ken

On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=l3eCnv-fXfurBfUcrBNHqCKlRe72qQ3nagQmrm6q3hohEnD3O9vTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
Thanks Ken. I was moving a few cone sources around (about 50) with SetPosition() and I see that they called Modified() which I'm guessing changes MTime? It was mostly for debugging because I can actually get around some of this in shaders to avoid going through the rendering pipeline. But, there are times when I need to move actors in real time, so this can sometimes be a bottleneck for me.

Thanks,
Nick
________________________________
From: Ken Martin [ken.martin at kitware.com<redir.aspx?REF=7NKZWv2KRrCx1AgMw-AKD2EBEOZ_yHLwuWYC7a5YyuOCc3L3O9vTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>]
Sent: Friday, September 09, 2016 5:58 PM
To: Milef, Nicholas Boris
Cc: vtk-developers at vtk.org<redir.aspx?REF=8tUHUt7Em6OuoDLP0IXTEnWAkYtBimEmdiUgStsNrreCc3L3O9vTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

When  GetNeedToRebuildShaders returns true. Which roughly is

  if (cellBO.Program == 0 ||
      cellBO.ShaderSourceTime < this->GetMTime() ||
      cellBO.ShaderSourceTime < actor->GetMTime() ||
      cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
      cellBO.ShaderSourceTime < this->SelectionStateChanged ||
      cellBO.ShaderSourceTime < renderPassMTime ||
      cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
    {
    return true;
    }

So if the main points are if you are modifying the actor, mapper, or your data. If one of those is being modified every frame then let me know the use case and we can see if the current test is being too aggressive etc.

Thanks
Ken




On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=-s-oZV-byzl2P_pLPynS3HwuAxI2Vyj3mIunkfvWblWCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9T05QRk9mVTJicHpwc3JjSWd0Mm03aGhFV1VKTkpvaFpCUERzWl9CRzRnUE9RN2tZX3RqVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>> wrote:
Under what conditions are shaders actually rebuilt? This seems to be the source of my performance issues and I need to know how to avoid this. The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that they get rebuilt when an object gets modified, is this true?

Thanks,
Nick

_______________________________________________
Powered by www.kitware.com<redir.aspx?REF=ZcAxHLY_Ai0kHKUODgMcw2uLy35zofRh9M6pbYHCbkuCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ejBsb29jalpWZVJ2S1A2NEV3cklnU1V4ZDIwZ21ua1VNV2Rfam16M1g5Z3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<redir.aspx?REF=MpFChAIndVF-31BDu1P8GKkFmMeEPgpFBoLJJWfQGXaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9eGpMMFpCbGVEX2hPcDZneVRXQ1haZzNPYTg4LThWYk5oYTNjRTNRRDRMd3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0TDI5d1pXNXpiM1Z5WTJVdmIzQmxibk52ZFhKalpTNW9kRzFz>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<redir.aspx?REF=h2JdIPhpR-0_gSeMqI67VlYMGejBp5iZLs5f8xgEgr-Cc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9RjF3Y00tTVdIbzA0dmpTMnZFX1BmUnNHRkxPQnVvb0FmSHVUSkdHdl9mQXZwYnNZX3RqVENBRm9kSFJ3T2k4dmJXRnlhMjFoYVd3dWIzSm5MM05sWVhKamFDOF9jVDEyZEdzdFpHVjJaV3h2Y0dWeWN3Li4.>

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers<redir.aspx?REF=vFatRmULlvJQdJKcGoY-cVxmEzdq4GlVUvkrY43iExaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TWhXQkFldllOaXFLTkhibHlwMFlQdUFpRXJ3dXFFNGdkeEFqVXFxTy0wWXZwYnNZX3RqVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmRuUnJMV1JsZG1Wc2IzQmxjbk0u>





--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971<tel:518%20371%203971>

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.



--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160912/7c3c0a0c/attachment.html>

From ken.martin at kitware.com  Mon Sep 12 14:52:52 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Mon, 12 Sep 2016 14:52:52 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
Message-ID: <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>

I committed a change in the past couple weeks to improve that. So if you
are using an older VTK updating may help.

On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Thanks, that's very helpful! During my performance analysis, I also saw in
> the UpdateShader() method, updating the shader uniforms took up a lot of
> CPU time as well (at least 40% of the total CPU time). Is it possible to
> add more aggressive modification checks to this? For instance, some of the
> uniforms such as color may never change.
>
> Thanks,
> Nick
> ------------------------------
> *From:* Ken Martin [ken.martin at kitware.com]
> *Sent:* Monday, September 12, 2016 9:55 AM
> *To:* Milef, Nicholas Boris
> *Cc:* vtk-developers at vtk.org
> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
> called?
>
> Thanks. I need to make that test more conservative. I'll try making a
> topic soon to update it. Probably what it needs is
>
> (actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
> (actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||
>
> as opposed to the
>
> actor->GetMTime() > ...
>
> line
>
> Thanks
> Ken
>
> On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu
> <http://redir.aspx?REF=l3eCnv-fXfurBfUcrBNHqCKlRe72qQ3nagQmrm6q3hohEnD3O9vTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
> > wrote:
>
>> Thanks Ken. I was moving a few cone sources around (about 50) with
>> SetPosition() and I see that they called Modified() which I'm guessing
>> changes MTime? It was mostly for debugging because I can actually get
>> around some of this in shaders to avoid going through the rendering
>> pipeline. But, there are times when I need to move actors in real time, so
>> this can sometimes be a bottleneck for me.
>>
>> Thanks,
>> Nick
>> ------------------------------
>> *From:* Ken Martin [ken.martin at kitware.com
>> <http://redir.aspx?REF=7NKZWv2KRrCx1AgMw-AKD2EBEOZ_yHLwuWYC7a5YyuOCc3L3O9vTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>> ]
>> *Sent:* Friday, September 09, 2016 5:58 PM
>> *To:* Milef, Nicholas Boris
>> *Cc:* vtk-developers at vtk.org
>> <http://redir.aspx?REF=8tUHUt7Em6OuoDLP0IXTEnWAkYtBimEmdiUgStsNrreCc3L3O9vTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
>> called?
>>
>> When  GetNeedToRebuildShaders returns true. Which roughly is
>>
>>   if (cellBO.Program == 0 ||
>>       cellBO.ShaderSourceTime < this->GetMTime() ||
>>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>>       cellBO.ShaderSourceTime < renderPassMTime ||
>>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>>     {
>>     return true;
>>     }
>>
>> So if the main points are if you are modifying the actor, mapper, or your
>> data. If one of those is being modified every frame then let me know the
>> use case and we can see if the current test is being too aggressive etc.
>>
>> Thanks
>> Ken
>>
>>
>>
>>
>> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=-s-oZV-byzl2P_pLPynS3HwuAxI2Vyj3mIunkfvWblWCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9T05QRk9mVTJicHpwc3JjSWd0Mm03aGhFV1VKTkpvaFpCUERzWl9CRzRnUE9RN2tZX3RqVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>> > wrote:
>>
>>> Under what conditions are shaders actually rebuilt? This seems to be the
>>> source of my performance issues and I need to know how to avoid this. The
>>> function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that
>>> they get rebuilt when an object gets modified, is this true?
>>>
>>> Thanks,
>>> Nick
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> <http://redir.aspx?REF=ZcAxHLY_Ai0kHKUODgMcw2uLy35zofRh9M6pbYHCbkuCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ejBsb29jalpWZVJ2S1A2NEV3cklnU1V4ZDIwZ21ua1VNV2Rfam16M1g5Z3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> <http://redir.aspx?REF=MpFChAIndVF-31BDu1P8GKkFmMeEPgpFBoLJJWfQGXaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9eGpMMFpCbGVEX2hPcDZneVRXQ1haZzNPYTg4LThWYk5oYTNjRTNRRDRMd3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0TDI5d1pXNXpiM1Z5WTJVdmIzQmxibk52ZFhKalpTNW9kRzFz>
>>>
>>> Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>> <http://redir.aspx?REF=h2JdIPhpR-0_gSeMqI67VlYMGejBp5iZLs5f8xgEgr-Cc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9RjF3Y00tTVdIbzA0dmpTMnZFX1BmUnNHRkxPQnVvb0FmSHVUSkdHdl9mQXZwYnNZX3RqVENBRm9kSFJ3T2k4dmJXRnlhMjFoYVd3dWIzSm5MM05sWVhKamFDOF9jVDEyZEdzdFpHVjJaV3h2Y0dWeWN3Li4.>
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>> <http://redir.aspx?REF=vFatRmULlvJQdJKcGoY-cVxmEzdq4GlVUvkrY43iExaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TWhXQkFldllOaXFLTkhibHlwMFlQdUFpRXJ3dXFFNGdkeEFqVXFxTy0wWXZwYnNZX3RqVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmRuUnJMV1JsZG1Wc2IzQmxjbk0u>
>>>
>>>
>>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>



-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160912/922048be/attachment-0001.html>

From david.lonie at kitware.com  Tue Sep 13 09:45:09 2016
From: david.lonie at kitware.com (David Lonie)
Date: Tue, 13 Sep 2016 09:45:09 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
 <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>
Message-ID: <CA+=e1os0yeV_wUBheZTG=u1KFuBnfihbMYGUHKHnH-adWX_V2A@mail.gmail.com>

Are you rendering any translucent geometry with depth peeling enabled? The
dual depth peeling passes call BuildShaders multiple times (2-3, IIRC) per
frame since different shaders are needed for different passes.

Dave

On Mon, Sep 12, 2016 at 2:52 PM, Ken Martin <ken.martin at kitware.com> wrote:

> I committed a change in the past couple weeks to improve that. So if you
> are using an older VTK updating may help.
>
> On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> Thanks, that's very helpful! During my performance analysis, I also saw
>> in the UpdateShader() method, updating the shader uniforms took up a lot of
>> CPU time as well (at least 40% of the total CPU time). Is it possible to
>> add more aggressive modification checks to this? For instance, some of the
>> uniforms such as color may never change.
>>
>> Thanks,
>> Nick
>> ------------------------------
>> *From:* Ken Martin [ken.martin at kitware.com]
>> *Sent:* Monday, September 12, 2016 9:55 AM
>> *To:* Milef, Nicholas Boris
>> *Cc:* vtk-developers at vtk.org
>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
>> called?
>>
>> Thanks. I need to make that test more conservative. I'll try making a
>> topic soon to update it. Probably what it needs is
>>
>> (actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
>> (actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||
>>
>> as opposed to the
>>
>> actor->GetMTime() > ...
>>
>> line
>>
>> Thanks
>> Ken
>>
>> On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=l3eCnv-fXfurBfUcrBNHqCKlRe72qQ3nagQmrm6q3hohEnD3O9vTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > wrote:
>>
>>> Thanks Ken. I was moving a few cone sources around (about 50) with
>>> SetPosition() and I see that they called Modified() which I'm guessing
>>> changes MTime? It was mostly for debugging because I can actually get
>>> around some of this in shaders to avoid going through the rendering
>>> pipeline. But, there are times when I need to move actors in real time, so
>>> this can sometimes be a bottleneck for me.
>>>
>>> Thanks,
>>> Nick
>>> ------------------------------
>>> *From:* Ken Martin [ken.martin at kitware.com
>>> <http://redir.aspx?REF=7NKZWv2KRrCx1AgMw-AKD2EBEOZ_yHLwuWYC7a5YyuOCc3L3O9vTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>>> ]
>>> *Sent:* Friday, September 09, 2016 5:58 PM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* vtk-developers at vtk.org
>>> <http://redir.aspx?REF=8tUHUt7Em6OuoDLP0IXTEnWAkYtBimEmdiUgStsNrreCc3L3O9vTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>> being called?
>>>
>>> When  GetNeedToRebuildShaders returns true. Which roughly is
>>>
>>>   if (cellBO.Program == 0 ||
>>>       cellBO.ShaderSourceTime < this->GetMTime() ||
>>>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>>>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>>>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>>>       cellBO.ShaderSourceTime < renderPassMTime ||
>>>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>>>     {
>>>     return true;
>>>     }
>>>
>>> So if the main points are if you are modifying the actor, mapper, or
>>> your data. If one of those is being modified every frame then let me know
>>> the use case and we can see if the current test is being too aggressive etc.
>>>
>>> Thanks
>>> Ken
>>>
>>>
>>>
>>>
>>> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=-s-oZV-byzl2P_pLPynS3HwuAxI2Vyj3mIunkfvWblWCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9T05QRk9mVTJicHpwc3JjSWd0Mm03aGhFV1VKTkpvaFpCUERzWl9CRzRnUE9RN2tZX3RqVENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>> > wrote:
>>>
>>>> Under what conditions are shaders actually rebuilt? This seems to be
>>>> the source of my performance issues and I need to know how to avoid this.
>>>> The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems
>>>> that they get rebuilt when an object gets modified, is this true?
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> <http://redir.aspx?REF=ZcAxHLY_Ai0kHKUODgMcw2uLy35zofRh9M6pbYHCbkuCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9ejBsb29jalpWZVJ2S1A2NEV3cklnU1V4ZDIwZ21ua1VNV2Rfam16M1g5Z3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0>
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> <http://redir.aspx?REF=MpFChAIndVF-31BDu1P8GKkFmMeEPgpFBoLJJWfQGXaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9eGpMMFpCbGVEX2hPcDZneVRXQ1haZzNPYTg4LThWYk5oYTNjRTNRRDRMd3ZwYnNZX3RqVENBRm9kSFJ3T2k4dmQzZDNMbXRwZEhkaGNtVXVZMjl0TDI5d1pXNXpiM1Z5WTJVdmIzQmxibk52ZFhKalpTNW9kRzFz>
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=
>>>> vtk-developers
>>>> <http://redir.aspx?REF=h2JdIPhpR-0_gSeMqI67VlYMGejBp5iZLs5f8xgEgr-Cc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9RjF3Y00tTVdIbzA0dmpTMnZFX1BmUnNHRkxPQnVvb0FmSHVUSkdHdl9mQXZwYnNZX3RqVENBRm9kSFJ3T2k4dmJXRnlhMjFoYVd3dWIzSm5MM05sWVhKamFDOF9jVDEyZEdzdFpHVjJaV3h2Y0dWeWN3Li4.>
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>> <http://redir.aspx?REF=vFatRmULlvJQdJKcGoY-cVxmEzdq4GlVUvkrY43iExaCc3L3O9vTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TWhXQkFldllOaXFLTkhibHlwMFlQdUFpRXJ3dXFFNGdkeEFqVXFxTy0wWXZwYnNZX3RqVENBRm9kSFJ3T2k4dmNIVmliR2xqTG10cGRIZGhjbVV1WTI5dEwyMWhhV3h0WVc0dmJHbHpkR2x1Wm04dmRuUnJMV1JsZG1Wc2IzQmxjbk0u>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ken Martin PhD
>>> Chairman & CFO
>>> Kitware Inc.
>>> 28 Corporate Drive
>>> Clifton Park NY 12065
>>> 518 371 3971
>>>
>>> This communication, including all attachments, contains confidential and
>>> legally privileged information, and it is intended only for the use of the
>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>> not the intended recipient, any disclosure, copying, distribution or any
>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>> received this communication in error please notify us immediately and
>>> destroy the original message.  Thank you.
>>>
>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160913/94f8a8ff/attachment.html>

From david.gobbi at gmail.com  Wed Sep 14 11:32:02 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 14 Sep 2016 09:32:02 -0600
Subject: [vtk-developers] VTK 7.1 release
Message-ID: <CANwS1=FRuz1PE53AzyrBA2rEKwUVJSxwYyk8W+r1_anK2nFmeA@mail.gmail.com>

Just curious.

It doesn't matter to me whether it's tomorrow, a week from now, or a month
from now... I just don't want it to be a surprise when it happens ;)

Gitlab doesn't have a 7.1 milestone, which makes it hard to guess what will
or will not be in the release.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/214f970c/attachment.html>

From ben.boeckel at kitware.com  Wed Sep 14 11:43:20 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 14 Sep 2016 11:43:20 -0400
Subject: [vtk-developers] VTK 7.1 release
In-Reply-To: <CANwS1=FRuz1PE53AzyrBA2rEKwUVJSxwYyk8W+r1_anK2nFmeA@mail.gmail.com>
References: <CANwS1=FRuz1PE53AzyrBA2rEKwUVJSxwYyk8W+r1_anK2nFmeA@mail.gmail.com>
Message-ID: <20160914154320.GA17906@megas.kitware.com>

On Wed, Sep 14, 2016 at 09:32:02 -0600, David Gobbi wrote:
> Gitlab doesn't have a 7.1 milestone, which makes it hard to guess what will
> or will not be in the release.

Ah, it's basically the 7.0.1 milestone (which just sort of morphed into
it); I'll move it once I have a date estimate from Chuck and Dave.

--Ben

From ken.martin at kitware.com  Wed Sep 14 11:49:43 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Wed, 14 Sep 2016 11:49:43 -0400
Subject: [vtk-developers] Xwindows PixmapContextId
Message-ID: <CANXz0SZxgxAkrdHfdwH4RnOMN6uybhEZoi-=50OSK6JesmcFjQ@mail.gmail.com>

There is some code in vtkXOpenGLRenderWindow that handles opengl contexts
based on a Pixmap. I cannot find any code in VTK that sets that ivar. Just
lots of code for handling it. I am thinking of trying a topic to remove it
but figured I should ask if anyone knows what it is about or if it is used.

Thanks
Ken


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/e58eeb10/attachment.html>

From milefn at rpi.edu  Wed Sep 14 12:59:33 2016
From: milefn at rpi.edu (Milef, Nicholas Boris)
Date: Wed, 14 Sep 2016 16:59:33 +0000
Subject: [vtk-developers] Why is BuildShaders() continuously being
 called?
In-Reply-To: <CA+=e1os0yeV_wUBheZTG=u1KFuBnfihbMYGUHKHnH-adWX_V2A@mail.gmail.com>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
 <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>,
 <CA+=e1os0yeV_wUBheZTG=u1KFuBnfihbMYGUHKHnH-adWX_V2A@mail.gmail.com>
Message-ID: <C745C1E748CE104AA373B656E0EF5E301D1757@ex14mb4.win.rpi.edu>

@Ken, my version is a week or two old, it's forked from your fork, so it's possible I missed the commit.

@Dave, no I'm not using transparency at all. I had around 50-60 totally opaque objects moving at the same time though, although the triangle counts were not huge. This is somewhat unrelated, but why would different shaders be needed for different passes? Or is it because it renders with multiple passes, which calls rebuild shaders?
________________________________
From: David Lonie [david.lonie at kitware.com]
Sent: Tuesday, September 13, 2016 9:45 AM
To: Ken Martin
Cc: Milef, Nicholas Boris; vtk-developers at vtk.org
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

Are you rendering any translucent geometry with depth peeling enabled? The dual depth peeling passes call BuildShaders multiple times (2-3, IIRC) per frame since different shaders are needed for different passes.

Dave

On Mon, Sep 12, 2016 at 2:52 PM, Ken Martin <ken.martin at kitware.com<redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>> wrote:
I committed a change in the past couple weeks to improve that. So if you are using an older VTK updating may help.

On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=IkNIosyEmsnLhMNAADfPrVIBZPo_Hnc4ZT0JaDo0lsmVnH-TvtzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>> wrote:
Thanks, that's very helpful! During my performance analysis, I also saw in the UpdateShader() method, updating the shader uniforms took up a lot of CPU time as well (at least 40% of the total CPU time). Is it possible to add more aggressive modification checks to this? For instance, some of the uniforms such as color may never change.

Thanks,
Nick
________________________________
From: Ken Martin [ken.martin at kitware.com<redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>]
Sent: Monday, September 12, 2016 9:55 AM
To: Milef, Nicholas Boris
Cc: vtk-developers at vtk.org<redir.aspx?REF=77gOhYDGaJONRKJZVSyinhENqvLqts2nnbZNrVFlG62VnH-TvtzTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

Thanks. I need to make that test more conservative. I'll try making a topic soon to update it. Probably what it needs is

(actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
(actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||

as opposed to the

actor->GetMTime() > ...

line

Thanks
Ken

On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=EBeZB359llDrjd-nwo3MM-Xzz_a5SWpZGMi3KrAIdp6VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9bDNlQ252LWZYZnVyQmZVY3JCTkhxQ0tsUmU3MnFRM25hZ1Ftcm02cTNob2hFbkQzTzl2VENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>> wrote:
Thanks Ken. I was moving a few cone sources around (about 50) with SetPosition() and I see that they called Modified() which I'm guessing changes MTime? It was mostly for debugging because I can actually get around some of this in shaders to avoid going through the rendering pipeline. But, there are times when I need to move actors in real time, so this can sometimes be a bottleneck for me.

Thanks,
Nick
________________________________
From: Ken Martin [ken.martin at kitware.com<redir.aspx?REF=FYnPTePbI0oUN9yrk5e5gJMlFpmxUnh2Muh7Mr_VnyyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9N05LWld2MktSckN4MUFnTXctQUtEMkVCRU9aX3lITHd1V1lDN2E1WXl1T0NjM0wzTzl2VENBRnRZV2xzZEc4NmEyVnVMbTFoY25ScGJrQnJhWFIzWVhKbExtTnZiUS4u>]
Sent: Friday, September 09, 2016 5:58 PM
To: Milef, Nicholas Boris
Cc: vtk-developers at vtk.org<redir.aspx?REF=4k8Yz64tdln9TkQdZJIZLZ2a_k8z1aC8dwH_5Qkyw4iVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9OHRVSFV0N0VtNk91b0RMUDBJWFRFbldBa1l0QmltRW1kaVVnU3RzTnJyZUNjM0wzTzl2VENBRnRZV2xzZEc4NmRuUnJMV1JsZG1Wc2IzQmxjbk5BZG5SckxtOXlady4u>
Subject: Re: [vtk-developers] Why is BuildShaders() continuously being called?

When  GetNeedToRebuildShaders returns true. Which roughly is

  if (cellBO.Program == 0 ||
      cellBO.ShaderSourceTime < this->GetMTime() ||
      cellBO.ShaderSourceTime < actor->GetMTime() ||
      cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
      cellBO.ShaderSourceTime < this->SelectionStateChanged ||
      cellBO.ShaderSourceTime < renderPassMTime ||
      cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
    {
    return true;
    }

So if the main points are if you are modifying the actor, mapper, or your data. If one of those is being modified every frame then let me know the use case and we can see if the current test is being too aggressive etc.

Thanks
Ken




On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu<redir.aspx?REF=gpnYISvvDOAs1AE2npqTuRzDPoJjLoTAOKCG6xGJvPiVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9LXMtb1pWLWJ5emwyUF9wTFB5blMzSHd1QXhJMlZ5ajNtSXVua2Z2V2JsV0NjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VDA1UVJrOW1WVEppY0hwd2MzSmpTV2QwTW0wM2FHaEZWMVZLVGtwdmFGcENVRVJ6V2w5Q1J6Um5VRTlSTjJ0WlgzUnFWRU5CUm5SWlYyeHpaRWM0Tm1KWGJITmFWMXAxVVVoS2QyRlROV3hhU0ZVdQ..>> wrote:
Under what conditions are shaders actually rebuilt? This seems to be the source of my performance issues and I need to know how to avoid this. The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems that they get rebuilt when an object gets modified, is this true?

Thanks,
Nick

_______________________________________________
Powered by www.kitware.com<redir.aspx?REF=IekiU072T4tQkKA1EhP2yERF4NSsNbcM4v5Y-KsekYKVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9WmNBeEhMWV9BaTBrSEtVT0RnTWN3MnVMeTM1em9mUmg5TTZwYllIQ2JrdUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZWpCc2IyOWphbHBXWlZKMlMxQTJORVYzY2tsblUxVjRaREl3WjIxdWExVk5WMlJmYW0xNk0xZzVaM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMA..>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<redir.aspx?REF=vZYlEbhL0pDguM7Vb_XvVr611N53JtyMjMgCuPKdZc-VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TXBGQ2hBSW5kVkYtMzFCRHUxUDhHS2tGbU1lRVBncEZCb0xKSldmUUdYYUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZUdwTU1GcENiR1ZFWDJoUGNEWm5lVlJYUTFoYVp6TlBZVGc0TFRoV1lrNW9ZVE5qUlROUlJEUk1kM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMFRESTVkMXBYTlhwaU0xWjVXVEpWZG1JelFteGliazUyWkZoS2FscFROVzlrUnpGeg..>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<redir.aspx?REF=4PGrshj6Qo82lkGltS2-RFMur0lpjKIa9tkdXpjdLjyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9aDJKZElQaHBSLTBfZ1NlTXFJNjdWbFlNR2VqQnA1aVpMczVmOHhnRWdyLUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5UmpGM1kwMHRUVmRJYnpBMGRtcFRNblpGWDFCbVVuTkhSa3hQUW5WdmIwRm1TSFZVU2tkSGRsOW1RWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1KWFJubGhNakZvWVZkM2RXSXpTbTVNTTA1c1dWaEthbUZET0Y5alZERXlaRWR6ZEZwSFZqSmFWM2gyWTBkV2VXTjNMaTQu>

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers<redir.aspx?REF=EAlTZLQI3zlSDmRGiGgDemhmy2qt_qeMsjQBiwZsumGVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9dkZhdFJtVUxsdkpRZEpLY0dvWS1jVnhtRXpkcTRHbFZVdmtyWTQzaUV4YUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VFdoWFFrRmxkbGxPYVhGTFRraGliSGx3TUZsUWRVRnBSWEozZFhGRk5HZGtlRUZxVlhGeFR5MHdXWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1OSVZtbGlSMnhxVEcxMGNHUklaR2hqYlZWMVdUSTVkRXd5TVdoaFYzaDBXVmMwZG1KSGJIcGtSMngxV20wNGRtUnVVbkpNVjFKc1pHMVdjMkl6UW14amJrMHU.>





--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971<tel:518%20371%203971>

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.



--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971<tel:518%20371%203971>

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.



--
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971<tel:518%20371%203971>

This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee.  Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message.  Thank you.

_______________________________________________
Powered by www.kitware.com<redir.aspx?REF=26vIYSFmKUypZLnImmTpA4zelCFMO5ZLnX3KwnKIeHSVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<redir.aspx?REF=rpvekQp3gTZfZY3uH_gyBw870sETaSZvsK76ByQkaeGVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<redir.aspx?REF=oIxtxRakH3IHudjawXuHcyFGvxucJjABzwuPyWfs-MiVnH-TvtzTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers<redir.aspx?REF=FKtbOloD6O-enBFOofiP-siTqalWeju9pA52ojdhF7aVnH-TvtzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/0a2dd9b0/attachment.html>

From david.lonie at kitware.com  Wed Sep 14 13:02:41 2016
From: david.lonie at kitware.com (David Lonie)
Date: Wed, 14 Sep 2016 13:02:41 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D1757@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
 <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>
 <CA+=e1os0yeV_wUBheZTG=u1KFuBnfihbMYGUHKHnH-adWX_V2A@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D1757@ex14mb4.win.rpi.edu>
Message-ID: <CA+=e1ot11OWm9GYZmeuC=ecOoaDBCNMqRmnY6=aZL2QLYoWm8g@mail.gmail.com>

On Wed, Sep 14, 2016 at 12:59 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> @Dave, no I'm not using transparency at all. I had around 50-60 totally
> opaque objects moving at the same time though, although the triangle counts
> were not huge. This is somewhat unrelated, but why would different shaders
> be needed for different passes? Or is it because it renders with multiple
> passes, which calls rebuild shaders?
>

There are different passes that do different things in the fragment shader
to extract / blend translucent geometry. It will initialize depth buffers
in one pass, peel geometry the next set of passes, and optionally do simple
alpha blending in a final pass.

Dave


> ------------------------------
> *From:* David Lonie [david.lonie at kitware.com]
> *Sent:* Tuesday, September 13, 2016 9:45 AM
> *To:* Ken Martin
> *Cc:* Milef, Nicholas Boris; vtk-developers at vtk.org
>
> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
> called?
>
> Are you rendering any translucent geometry with depth peeling enabled? The
> dual depth peeling passes call BuildShaders multiple times (2-3, IIRC) per
> frame since different shaders are needed for different passes.
>
> Dave
>
> On Mon, Sep 12, 2016 at 2:52 PM, Ken Martin <ken.martin at kitware.com
> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
> > wrote:
>
>> I committed a change in the past couple weeks to improve that. So if you
>> are using an older VTK updating may help.
>>
>> On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=IkNIosyEmsnLhMNAADfPrVIBZPo_Hnc4ZT0JaDo0lsmVnH-TvtzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > wrote:
>>
>>> Thanks, that's very helpful! During my performance analysis, I also saw
>>> in the UpdateShader() method, updating the shader uniforms took up a lot of
>>> CPU time as well (at least 40% of the total CPU time). Is it possible to
>>> add more aggressive modification checks to this? For instance, some of the
>>> uniforms such as color may never change.
>>>
>>> Thanks,
>>> Nick
>>> ------------------------------
>>> *From:* Ken Martin [ken.martin at kitware.com
>>> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>>> ]
>>> *Sent:* Monday, September 12, 2016 9:55 AM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* vtk-developers at vtk.org
>>> <http://redir.aspx?REF=77gOhYDGaJONRKJZVSyinhENqvLqts2nnbZNrVFlG62VnH-TvtzTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>> being called?
>>>
>>> Thanks. I need to make that test more conservative. I'll try making a
>>> topic soon to update it. Probably what it needs is
>>>
>>> (actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
>>> (actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||
>>>
>>> as opposed to the
>>>
>>> actor->GetMTime() > ...
>>>
>>> line
>>>
>>> Thanks
>>> Ken
>>>
>>> On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=EBeZB359llDrjd-nwo3MM-Xzz_a5SWpZGMi3KrAIdp6VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9bDNlQ252LWZYZnVyQmZVY3JCTkhxQ0tsUmU3MnFRM25hZ1Ftcm02cTNob2hFbkQzTzl2VENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>> > wrote:
>>>
>>>> Thanks Ken. I was moving a few cone sources around (about 50) with
>>>> SetPosition() and I see that they called Modified() which I'm guessing
>>>> changes MTime? It was mostly for debugging because I can actually get
>>>> around some of this in shaders to avoid going through the rendering
>>>> pipeline. But, there are times when I need to move actors in real time, so
>>>> this can sometimes be a bottleneck for me.
>>>>
>>>> Thanks,
>>>> Nick
>>>> ------------------------------
>>>> *From:* Ken Martin [ken.martin at kitware.com
>>>> <http://redir.aspx?REF=FYnPTePbI0oUN9yrk5e5gJMlFpmxUnh2Muh7Mr_VnyyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9N05LWld2MktSckN4MUFnTXctQUtEMkVCRU9aX3lITHd1V1lDN2E1WXl1T0NjM0wzTzl2VENBRnRZV2xzZEc4NmEyVnVMbTFoY25ScGJrQnJhWFIzWVhKbExtTnZiUS4u>
>>>> ]
>>>> *Sent:* Friday, September 09, 2016 5:58 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* vtk-developers at vtk.org
>>>> <http://redir.aspx?REF=4k8Yz64tdln9TkQdZJIZLZ2a_k8z1aC8dwH_5Qkyw4iVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9OHRVSFV0N0VtNk91b0RMUDBJWFRFbldBa1l0QmltRW1kaVVnU3RzTnJyZUNjM0wzTzl2VENBRnRZV2xzZEc4NmRuUnJMV1JsZG1Wc2IzQmxjbk5BZG5SckxtOXlady4u>
>>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>>> being called?
>>>>
>>>> When  GetNeedToRebuildShaders returns true. Which roughly is
>>>>
>>>>   if (cellBO.Program == 0 ||
>>>>       cellBO.ShaderSourceTime < this->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>>>>       cellBO.ShaderSourceTime < renderPassMTime ||
>>>>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>>>>     {
>>>>     return true;
>>>>     }
>>>>
>>>> So if the main points are if you are modifying the actor, mapper, or
>>>> your data. If one of those is being modified every frame then let me know
>>>> the use case and we can see if the current test is being too aggressive etc.
>>>>
>>>> Thanks
>>>> Ken
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> <http://redir.aspx?REF=gpnYISvvDOAs1AE2npqTuRzDPoJjLoTAOKCG6xGJvPiVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9LXMtb1pWLWJ5emwyUF9wTFB5blMzSHd1QXhJMlZ5ajNtSXVua2Z2V2JsV0NjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VDA1UVJrOW1WVEppY0hwd2MzSmpTV2QwTW0wM2FHaEZWMVZLVGtwdmFGcENVRVJ6V2w5Q1J6Um5VRTlSTjJ0WlgzUnFWRU5CUm5SWlYyeHpaRWM0Tm1KWGJITmFWMXAxVVVoS2QyRlROV3hhU0ZVdQ..>
>>>> > wrote:
>>>>
>>>>> Under what conditions are shaders actually rebuilt? This seems to be
>>>>> the source of my performance issues and I need to know how to avoid this.
>>>>> The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems
>>>>> that they get rebuilt when an object gets modified, is this true?
>>>>>
>>>>> Thanks,
>>>>> Nick
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> <http://redir.aspx?REF=IekiU072T4tQkKA1EhP2yERF4NSsNbcM4v5Y-KsekYKVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9WmNBeEhMWV9BaTBrSEtVT0RnTWN3MnVMeTM1em9mUmg5TTZwYllIQ2JrdUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZWpCc2IyOWphbHBXWlZKMlMxQTJORVYzY2tsblUxVjRaREl3WjIxdWExVk5WMlJmYW0xNk0xZzVaM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMA..>
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> <http://redir.aspx?REF=vZYlEbhL0pDguM7Vb_XvVr611N53JtyMjMgCuPKdZc-VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TXBGQ2hBSW5kVkYtMzFCRHUxUDhHS2tGbU1lRVBncEZCb0xKSldmUUdYYUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZUdwTU1GcENiR1ZFWDJoUGNEWm5lVlJYUTFoYVp6TlBZVGc0TFRoV1lrNW9ZVE5qUlROUlJEUk1kM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMFRESTVkMXBYTlhwaU0xWjVXVEpWZG1JelFteGliazUyWkZoS2FscFROVzlrUnpGeg..>
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>> vtk-developers
>>>>> <http://redir.aspx?REF=4PGrshj6Qo82lkGltS2-RFMur0lpjKIa9tkdXpjdLjyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9aDJKZElQaHBSLTBfZ1NlTXFJNjdWbFlNR2VqQnA1aVpMczVmOHhnRWdyLUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5UmpGM1kwMHRUVmRJYnpBMGRtcFRNblpGWDFCbVVuTkhSa3hQUW5WdmIwRm1TSFZVU2tkSGRsOW1RWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1KWFJubGhNakZvWVZkM2RXSXpTbTVNTTA1c1dWaEthbUZET0Y5alZERXlaRWR6ZEZwSFZqSmFWM2gyWTBkV2VXTjNMaTQu>
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>> <http://redir.aspx?REF=EAlTZLQI3zlSDmRGiGgDemhmy2qt_qeMsjQBiwZsumGVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9dkZhdFJtVUxsdkpRZEpLY0dvWS1jVnhtRXpkcTRHbFZVdmtyWTQzaUV4YUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VFdoWFFrRmxkbGxPYVhGTFRraGliSGx3TUZsUWRVRnBSWEozZFhGRk5HZGtlRUZxVlhGeFR5MHdXWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1OSVZtbGlSMnhxVEcxMGNHUklaR2hqYlZWMVdUSTVkRXd5TVdoaFYzaDBXVmMwZG1KSGJIcGtSMngxV20wNGRtUnVVbkpNVjFKc1pHMVdjMkl6UW14amJrMHU.>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ken Martin PhD
>>>> Chairman & CFO
>>>> Kitware Inc.
>>>> 28 Corporate Drive
>>>> Clifton Park NY 12065
>>>> 518 371 3971
>>>>
>>>> This communication, including all attachments, contains confidential
>>>> and legally privileged information, and it is intended only for the use of
>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>> you received this communication in error please notify us immediately and
>>>> destroy the original message.  Thank you.
>>>>
>>>
>>>
>>>
>>> --
>>> Ken Martin PhD
>>> Chairman & CFO
>>> Kitware Inc.
>>> 28 Corporate Drive
>>> Clifton Park NY 12065
>>> 518 371 3971
>>>
>>> This communication, including all attachments, contains confidential and
>>> legally privileged information, and it is intended only for the use of the
>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>> not the intended recipient, any disclosure, copying, distribution or any
>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>> received this communication in error please notify us immediately and
>>> destroy the original message.  Thank you.
>>>
>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>> _______________________________________________
>> Powered by www.kitware.com
>> <http://redir.aspx?REF=26vIYSFmKUypZLnImmTpA4zelCFMO5ZLnX3KwnKIeHSVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> <http://redir.aspx?REF=rpvekQp3gTZfZY3uH_gyBw870sETaSZvsK76ByQkaeGVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>> <http://redir.aspx?REF=oIxtxRakH3IHudjawXuHcyFGvxucJjABzwuPyWfs-MiVnH-TvtzTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>> <http://redir.aspx?REF=FKtbOloD6O-enBFOofiP-siTqalWeju9pA52ojdhF7aVnH-TvtzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/17e7e254/attachment-0001.html>

From ken.martin at kitware.com  Wed Sep 14 13:09:43 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Wed, 14 Sep 2016 13:09:43 -0400
Subject: [vtk-developers] Why is BuildShaders() continuously being
	called?
In-Reply-To: <C745C1E748CE104AA373B656E0EF5E301D1757@ex14mb4.win.rpi.edu>
References: <C745C1E748CE104AA373B656E0EF5E301D14AD@ex14mb4.win.rpi.edu>
 <CANXz0SY_UBZimccbMai+MLYaukz5oqYh+ziTpzUnuraQmdkhCQ@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D14D2@ex14mb4.win.rpi.edu>
 <CANXz0Sav1FZF1aYwpM0WMFDR71pyGS_roc6cf-PE2K2sqNf=0Q@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D160D@ex14mb4.win.rpi.edu>
 <CANXz0Sacat8CVzFDxRoCn3FjKQVas2ETutSRZx-mT8AZ-WWE1A@mail.gmail.com>
 <CA+=e1os0yeV_wUBheZTG=u1KFuBnfihbMYGUHKHnH-adWX_V2A@mail.gmail.com>
 <C745C1E748CE104AA373B656E0EF5E301D1757@ex14mb4.win.rpi.edu>
Message-ID: <CANXz0SY86Jg4GP1fYOmi3ZukO7om-yHuBY4pOEc0tWu-DXxKig@mail.gmail.com>

You can check if you have the faster version by looking in
OpenGL2/vtkShaderProgram.h for

  // maps of std::string are super slow when calling find
  // with a string literal or const char * as find
  // forces construction/copy/destruction of a
  // std::sting copy of the const char *
  // In spite of the doubters this can really be a
  // huge CPU hog.
  struct cmp_str
  {
     bool operator()(const char *a, const char *b) const
     {
        return strcmp(a, b) < 0;
     }
  };

If you have it, then you have the faster version.

Thanks
Ken


On Wed, Sep 14, 2016 at 12:59 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> @Ken, my version is a week or two old, it's forked from your fork, so it's
> possible I missed the commit.
>
> @Dave, no I'm not using transparency at all. I had around 50-60 totally
> opaque objects moving at the same time though, although the triangle counts
> were not huge. This is somewhat unrelated, but why would different shaders
> be needed for different passes? Or is it because it renders with multiple
> passes, which calls rebuild shaders?
> ------------------------------
> *From:* David Lonie [david.lonie at kitware.com]
> *Sent:* Tuesday, September 13, 2016 9:45 AM
> *To:* Ken Martin
> *Cc:* Milef, Nicholas Boris; vtk-developers at vtk.org
> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously being
> called?
>
> Are you rendering any translucent geometry with depth peeling enabled? The
> dual depth peeling passes call BuildShaders multiple times (2-3, IIRC) per
> frame since different shaders are needed for different passes.
>
> Dave
>
> On Mon, Sep 12, 2016 at 2:52 PM, Ken Martin <ken.martin at kitware.com
> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
> > wrote:
>
>> I committed a change in the past couple weeks to improve that. So if you
>> are using an older VTK updating may help.
>>
>> On Mon, Sep 12, 2016 at 2:49 PM, Milef, Nicholas Boris <milefn at rpi.edu
>> <http://redir.aspx?REF=IkNIosyEmsnLhMNAADfPrVIBZPo_Hnc4ZT0JaDo0lsmVnH-TvtzTCAFtYWlsdG86bWlsZWZuQHJwaS5lZHU.>
>> > wrote:
>>
>>> Thanks, that's very helpful! During my performance analysis, I also saw
>>> in the UpdateShader() method, updating the shader uniforms took up a lot of
>>> CPU time as well (at least 40% of the total CPU time). Is it possible to
>>> add more aggressive modification checks to this? For instance, some of the
>>> uniforms such as color may never change.
>>>
>>> Thanks,
>>> Nick
>>> ------------------------------
>>> *From:* Ken Martin [ken.martin at kitware.com
>>> <http://redir.aspx?REF=CEOyXTolh-4P2D-iEonQ2IxokEL2ZZjgiza5K3c2WtWVnH-TvtzTCAFtYWlsdG86a2VuLm1hcnRpbkBraXR3YXJlLmNvbQ..>
>>> ]
>>> *Sent:* Monday, September 12, 2016 9:55 AM
>>> *To:* Milef, Nicholas Boris
>>> *Cc:* vtk-developers at vtk.org
>>> <http://redir.aspx?REF=77gOhYDGaJONRKJZVSyinhENqvLqts2nnbZNrVFlG62VnH-TvtzTCAFtYWlsdG86dnRrLWRldmVsb3BlcnNAdnRrLm9yZw..>
>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>> being called?
>>>
>>> Thanks. I need to make that test more conservative. I'll try making a
>>> topic soon to update it. Probably what it needs is
>>>
>>> (actor->GetProperty() && actor->GetProperty()->GetMTime() > ...) ||
>>> (actor->GetTexture() && actor->GetTexture()->GetMTime() > ...) ||
>>>
>>> as opposed to the
>>>
>>> actor->GetMTime() > ...
>>>
>>> line
>>>
>>> Thanks
>>> Ken
>>>
>>> On Fri, Sep 9, 2016 at 6:20 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>> <http://redir.aspx?REF=EBeZB359llDrjd-nwo3MM-Xzz_a5SWpZGMi3KrAIdp6VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9bDNlQ252LWZYZnVyQmZVY3JCTkhxQ0tsUmU3MnFRM25hZ1Ftcm02cTNob2hFbkQzTzl2VENBRnRZV2xzZEc4NmJXbHNaV1p1UUhKd2FTNWxaSFUu>
>>> > wrote:
>>>
>>>> Thanks Ken. I was moving a few cone sources around (about 50) with
>>>> SetPosition() and I see that they called Modified() which I'm guessing
>>>> changes MTime? It was mostly for debugging because I can actually get
>>>> around some of this in shaders to avoid going through the rendering
>>>> pipeline. But, there are times when I need to move actors in real time, so
>>>> this can sometimes be a bottleneck for me.
>>>>
>>>> Thanks,
>>>> Nick
>>>> ------------------------------
>>>> *From:* Ken Martin [ken.martin at kitware.com
>>>> <http://redir.aspx?REF=FYnPTePbI0oUN9yrk5e5gJMlFpmxUnh2Muh7Mr_VnyyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9N05LWld2MktSckN4MUFnTXctQUtEMkVCRU9aX3lITHd1V1lDN2E1WXl1T0NjM0wzTzl2VENBRnRZV2xzZEc4NmEyVnVMbTFoY25ScGJrQnJhWFIzWVhKbExtTnZiUS4u>
>>>> ]
>>>> *Sent:* Friday, September 09, 2016 5:58 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* vtk-developers at vtk.org
>>>> <http://redir.aspx?REF=4k8Yz64tdln9TkQdZJIZLZ2a_k8z1aC8dwH_5Qkyw4iVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9OHRVSFV0N0VtNk91b0RMUDBJWFRFbldBa1l0QmltRW1kaVVnU3RzTnJyZUNjM0wzTzl2VENBRnRZV2xzZEc4NmRuUnJMV1JsZG1Wc2IzQmxjbk5BZG5SckxtOXlady4u>
>>>> *Subject:* Re: [vtk-developers] Why is BuildShaders() continuously
>>>> being called?
>>>>
>>>> When  GetNeedToRebuildShaders returns true. Which roughly is
>>>>
>>>>   if (cellBO.Program == 0 ||
>>>>       cellBO.ShaderSourceTime < this->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < actor->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->CurrentInput->GetMTime() ||
>>>>       cellBO.ShaderSourceTime < this->SelectionStateChanged ||
>>>>       cellBO.ShaderSourceTime < renderPassMTime ||
>>>>       cellBO.ShaderSourceTime < this->LightComplexityChanged[&cellBO])
>>>>     {
>>>>     return true;
>>>>     }
>>>>
>>>> So if the main points are if you are modifying the actor, mapper, or
>>>> your data. If one of those is being modified every frame then let me know
>>>> the use case and we can see if the current test is being too aggressive etc.
>>>>
>>>> Thanks
>>>> Ken
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 9, 2016 at 5:47 PM, Milef, Nicholas Boris <milefn at rpi.edu
>>>> <http://redir.aspx?REF=gpnYISvvDOAs1AE2npqTuRzDPoJjLoTAOKCG6xGJvPiVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9LXMtb1pWLWJ5emwyUF9wTFB5blMzSHd1QXhJMlZ5ajNtSXVua2Z2V2JsV0NjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VDA1UVJrOW1WVEppY0hwd2MzSmpTV2QwTW0wM2FHaEZWMVZLVGtwdmFGcENVRVJ6V2w5Q1J6Um5VRTlSTjJ0WlgzUnFWRU5CUm5SWlYyeHpaRWM0Tm1KWGJITmFWMXAxVVVoS2QyRlROV3hhU0ZVdQ..>
>>>> > wrote:
>>>>
>>>>> Under what conditions are shaders actually rebuilt? This seems to be
>>>>> the source of my performance issues and I need to know how to avoid this.
>>>>> The function I'm referring to is in vtkOpenGLPolyDataMapper(). It seems
>>>>> that they get rebuilt when an object gets modified, is this true?
>>>>>
>>>>> Thanks,
>>>>> Nick
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> <http://redir.aspx?REF=IekiU072T4tQkKA1EhP2yERF4NSsNbcM4v5Y-KsekYKVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9WmNBeEhMWV9BaTBrSEtVT0RnTWN3MnVMeTM1em9mUmg5TTZwYllIQ2JrdUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZWpCc2IyOWphbHBXWlZKMlMxQTJORVYzY2tsblUxVjRaREl3WjIxdWExVk5WMlJmYW0xNk0xZzVaM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMA..>
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> <http://redir.aspx?REF=vZYlEbhL0pDguM7Vb_XvVr611N53JtyMjMgCuPKdZc-VnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9TXBGQ2hBSW5kVkYtMzFCRHUxUDhHS2tGbU1lRVBncEZCb0xKSldmUUdYYUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5ZUdwTU1GcENiR1ZFWDJoUGNEWm5lVlJYUTFoYVp6TlBZVGc0TFRoV1lrNW9ZVE5qUlROUlJEUk1kM1p3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1RelpETk1iWFJ3WkVoa2FHTnRWWFZaTWpsMFRESTVkMXBYTlhwaU0xWjVXVEpWZG1JelFteGliazUyWkZoS2FscFROVzlrUnpGeg..>
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>> vtk-developers
>>>>> <http://redir.aspx?REF=4PGrshj6Qo82lkGltS2-RFMur0lpjKIa9tkdXpjdLjyVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9aDJKZElQaHBSLTBfZ1NlTXFJNjdWbFlNR2VqQnA1aVpMczVmOHhnRWdyLUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5UmpGM1kwMHRUVmRJYnpBMGRtcFRNblpGWDFCbVVuTkhSa3hQUW5WdmIwRm1TSFZVU2tkSGRsOW1RWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1KWFJubGhNakZvWVZkM2RXSXpTbTVNTTA1c1dWaEthbUZET0Y5alZERXlaRWR6ZEZwSFZqSmFWM2gyWTBkV2VXTjNMaTQu>
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>> <http://redir.aspx?REF=EAlTZLQI3zlSDmRGiGgDemhmy2qt_qeMsjQBiwZsumGVnH-TvtzTCAFodHRwOi8vcmVkaXIuYXNweD9SRUY9dkZhdFJtVUxsdkpRZEpLY0dvWS1jVnhtRXpkcTRHbFZVdmtyWTQzaUV4YUNjM0wzTzl2VENBRm9kSFJ3T2k4dmNtVmthWEl1WVhOd2VEOVNSVVk5VFdoWFFrRmxkbGxPYVhGTFRraGliSGx3TUZsUWRVRnBSWEozZFhGRk5HZGtlRUZxVlhGeFR5MHdXWFp3WW5OWlgzUnFWRU5CUm05a1NGSjNUMms0ZG1OSVZtbGlSMnhxVEcxMGNHUklaR2hqYlZWMVdUSTVkRXd5TVdoaFYzaDBXVmMwZG1KSGJIcGtSMngxV20wNGRtUnVVbkpNVjFKc1pHMVdjMkl6UW14amJrMHU.>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ken Martin PhD
>>>> Chairman & CFO
>>>> Kitware Inc.
>>>> 28 Corporate Drive
>>>> Clifton Park NY 12065
>>>> 518 371 3971
>>>>
>>>> This communication, including all attachments, contains confidential
>>>> and legally privileged information, and it is intended only for the use of
>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>> you received this communication in error please notify us immediately and
>>>> destroy the original message.  Thank you.
>>>>
>>>
>>>
>>>
>>> --
>>> Ken Martin PhD
>>> Chairman & CFO
>>> Kitware Inc.
>>> 28 Corporate Drive
>>> Clifton Park NY 12065
>>> 518 371 3971
>>>
>>> This communication, including all attachments, contains confidential and
>>> legally privileged information, and it is intended only for the use of the
>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>> not the intended recipient, any disclosure, copying, distribution or any
>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>> received this communication in error please notify us immediately and
>>> destroy the original message.  Thank you.
>>>
>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>> _______________________________________________
>> Powered by www.kitware.com
>> <http://redir.aspx?REF=26vIYSFmKUypZLnImmTpA4zelCFMO5ZLnX3KwnKIeHSVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29t>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> <http://redir.aspx?REF=rpvekQp3gTZfZY3uH_gyBw870sETaSZvsK76ByQkaeGVnH-TvtzTCAFodHRwOi8vd3d3LmtpdHdhcmUuY29tL29wZW5zb3VyY2Uvb3BlbnNvdXJjZS5odG1s>
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>> <http://redir.aspx?REF=oIxtxRakH3IHudjawXuHcyFGvxucJjABzwuPyWfs-MiVnH-TvtzTCAFodHRwOi8vbWFya21haWwub3JnL3NlYXJjaC8_cT12dGstZGV2ZWxvcGVycw..>
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>> <http://redir.aspx?REF=FKtbOloD6O-enBFOofiP-siTqalWeju9pA52ojdhF7aVnH-TvtzTCAFodHRwOi8vcHVibGljLmtpdHdhcmUuY29tL21haWxtYW4vbGlzdGluZm8vdnRrLWRldmVsb3BlcnM.>
>>
>>
>>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/4df904a3/attachment-0001.html>

From clinton at elemtech.com  Wed Sep 14 14:39:04 2016
From: clinton at elemtech.com (clinton at elemtech.com)
Date: Wed, 14 Sep 2016 12:39:04 -0600 (MDT)
Subject: [vtk-developers] Xwindows PixmapContextId
In-Reply-To: <CANXz0SZxgxAkrdHfdwH4RnOMN6uybhEZoi-=50OSK6JesmcFjQ@mail.gmail.com>
References: <CANXz0SZxgxAkrdHfdwH4RnOMN6uybhEZoi-=50OSK6JesmcFjQ@mail.gmail.com>
Message-ID: <1774542786.2439835.1473878344348.JavaMail.zimbra@elemtech.com>

>From what I remember, it was added years ago to support offscreen rendering (probably added by myself). 
It did not require external code to make it work, so it sounds like its broken if there is no ivar setting it. 
Other methods have been developed and there are now better ways to do this. I think its ok to remove. 

Clint 

----- On Sep 14, 2016, at 9:49 AM, Ken Martin <ken.martin at kitware.com> wrote: 

> There is some code in vtkXOpenGLRenderWindow that handles opengl contexts based
> on a Pixmap. I cannot find any code in VTK that sets that ivar. Just lots of
> code for handling it. I am thinking of trying a topic to remove it but figured
> I should ask if anyone knows what it is about or if it is used.

> Thanks
> Ken

> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
> This communication, including all attachments, contains confidential and legally
> privileged information, and it is intended only for the use of the addressee.
> Access to this email by anyone else is unauthorized. If you are not the
> intended recipient, any disclosure, copying, distribution or any action taken
> in reliance on it is prohibited and may be unlawful. If you received this
> communication in error please notify us immediately and destroy the original
> message. Thank you.

> _______________________________________________
> Powered by www.kitware.com

> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html

> Search the list archives at: http://markmail.org/search/?q=vtk-developers

> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/f2d3c777/attachment.html>

From david.gobbi at gmail.com  Wed Sep 14 15:40:19 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Wed, 14 Sep 2016 13:40:19 -0600
Subject: [vtk-developers] Adding a connectivity filter for image data
Message-ID: <CANwS1=G5H2X-983JRbxfg+0EGjjW-Tq1Oq42fp+9H-yKzRQ2Sg@mail.gmail.com>

Hi All,

Yesterday I finally put together an MR for the vtkImageConnectivityFilter
that I wrote a long time ago:
http://gitlab.kitware.com/vtk/vtk/merge_requests/1946

The action of this filter is similar to the ScalarConnectivityOn() mode of
vtkConnectivityFilter, with the difference that vtkImageConnectivityFilter
labels connected points (its output is a label image with the same
dimensions as the input image), whereas vtkConnectivityFilter extracts
connected cells as an unstructured grid.

More documentation is provided on this wiki page that I wrote two years
ago, before I was sidetracked by other projects:
http://www.vtk.org/Wiki/VTK/Image_Connectivity

It provides the usual modes of operation like extracting the largest
region, extracting seeded regions, and it also allows the regions to be
ranked and filtered by size since this is a useful way of identifying
features of interest.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160914/3642f588/attachment.html>

From berk.geveci at kitware.com  Thu Sep 15 13:38:51 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Thu, 15 Sep 2016 13:38:51 -0400
Subject: [vtk-developers] Nightly failures
Message-ID: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>

Hi folks,

Two nightly dashboards are failing with the Tcl error below. Can whoever
caused this failure look into it?

Thanks,
-berk


Error in startup script: invalid command name "vtkTkImageViewerWidget"
    while executing
"vtkTkImageViewerWidget $viewer_frame.v \
        -width 264 \
        -height 264 \
        -iv viewer"
    (file "/home/kitware/Dashboards/My
Tests/VTK/Rendering/Tk/Testing/Tcl/cursor3D.tcl" line 169)
    invoked from within
"source $file"
    (file "/home/kitware/Dashboards/My
Tests/VTK/Testing/Rendering/rtImageTest.tcl" line 48)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/0bdbdc21/attachment.html>

From david.gobbi at gmail.com  Thu Sep 15 13:54:41 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 15 Sep 2016 11:54:41 -0600
Subject: [vtk-developers] Nightly failures
In-Reply-To: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
Message-ID: <CANwS1=EYX4F3aoWX-JoRnF9ZkzFubv773q1QhX0=QodS5kLUwg@mail.gmail.com>

This test started failing when all the module.cmake files were modified.

Most likely, the vtkTkImageViewerWidget is no longer being linked because
the dependencies have changed.  In other words, a line was probably
erroneously removed from a module.cmake file somewhere, since the
dependency in question is only "exercised" at run-time via dynamic loading.

On Thu, Sep 15, 2016 at 11:38 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Hi folks,
>
> Two nightly dashboards are failing with the Tcl error below. Can whoever
> caused this failure look into it?
>
> Thanks,
> -berk
>
>
> Error in startup script: invalid command name "vtkTkImageViewerWidget"
>     while executing
> "vtkTkImageViewerWidget $viewer_frame.v \
>         -width 264 \
>         -height 264 \
>         -iv viewer"
>     (file "/home/kitware/Dashboards/My Tests/VTK/Rendering/Tk/Testing/Tcl/cursor3D.tcl"
> line 169)
>     invoked from within
> "source $file"
>     (file "/home/kitware/Dashboards/My Tests/VTK/Testing/Rendering/rtImageTest.tcl"
> line 48)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/de0ebd5e/attachment.html>

From will.schroeder at kitware.com  Thu Sep 15 13:54:58 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Thu, 15 Sep 2016 13:54:58 -0400
Subject: [vtk-developers] VTK Textbook and User's Guide now available for
	download
Message-ID: <CAEiDrtVi8dBP_5jNd6fs1kmyiS0VtzxJk0ZVSyzk89fpuvHouQ@mail.gmail.com>

Kitware is releasing the VTK Textbook and VTK User's Guide for PDF
download. Follow the links below to a landing page where you can buy a
printed version, or download a PDF.

Longer term, the plan is to convert these books to LaTeX (from Framemaker)
and place the content into an open repository. The first step is to mostly
duplicate what exists now; eventually we have the ambitious goal to
completely rewrite / recombine / rethink the books. For example, using
VTK.js (under development now) to offer web interaction with examples etc.
We can certainly use the talents of the community to take this challenge
on, so if you are interested please let me know.

The Visualization Toolkit An Object-Oriented Approach to 3D Graphics (4th
ed.)
http://www.vtk.org/vtk-textbook/
pdf: http://www.kitware.com/products/books/VTKTextbook.pdf

*The VTK User?s Guide*
http://www.vtk.org/vtk-users-guide/
pdf: http://www.kitware.com/products/books/VTKUsersGuide.pdf

Best, please let me know if there are issues or concerns.
W

-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/32962145/attachment.html>

From haocheng.liu at kitware.com  Thu Sep 15 13:57:42 2016
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Thu, 15 Sep 2016 13:57:42 -0400
Subject: [vtk-developers] Nightly failures
In-Reply-To: <CANwS1=EYX4F3aoWX-JoRnF9ZkzFubv773q1QhX0=QodS5kLUwg@mail.gmail.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
 <CANwS1=EYX4F3aoWX-JoRnF9ZkzFubv773q1QhX0=QodS5kLUwg@mail.gmail.com>
Message-ID: <CACbTE7My_9sfrhhkpv41VP86A7rHfGHQAmNTyLbgLngWdbyXaA@mail.gmail.com>

Hi, I am the one  who just recently updated all the module.cmake files, I
would  see into this issue.

On Thu, Sep 15, 2016 at 1:54 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> This test started failing when all the module.cmake files were modified.
>
> Most likely, the vtkTkImageViewerWidget is no longer being linked because
> the dependencies have changed.  In other words, a line was probably
> erroneously removed from a module.cmake file somewhere, since the
> dependency in question is only "exercised" at run-time via dynamic loading.
>
>
> On Thu, Sep 15, 2016 at 11:38 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> Two nightly dashboards are failing with the Tcl error below. Can whoever
>> caused this failure look into it?
>>
>> Thanks,
>> -berk
>>
>>
>> Error in startup script: invalid command name "vtkTkImageViewerWidget"
>>     while executing
>> "vtkTkImageViewerWidget $viewer_frame.v \
>>         -width 264 \
>>         -height 264 \
>>         -iv viewer"
>>     (file "/home/kitware/Dashboards/My Tests/VTK/Rendering/Tk/Testing/Tcl/cursor3D.tcl"
>> line 169)
>>     invoked from within
>> "source $file"
>>     (file "/home/kitware/Dashboards/My Tests/VTK/Testing/Rendering/rtImageTest.tcl"
>> line 48)
>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Best regards
Haocheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/e3865cda/attachment.html>

From matthew.brett at gmail.com  Thu Sep 15 15:48:26 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 15 Sep 2016 12:48:26 -0700
Subject: [vtk-developers] [ITK] [ITK-users] [ITK-dev] VTK Textbook and
 User's Guide now available for download
In-Reply-To: <CAHwLD2XspFeiW4BmkEf7LWs_P=iSoQQVjxWM3x5V9eKnp4DATA@mail.gmail.com>
References: <CAEiDrtVi8dBP_5jNd6fs1kmyiS0VtzxJk0ZVSyzk89fpuvHouQ@mail.gmail.com>
 <CAHwLD2XspFeiW4BmkEf7LWs_P=iSoQQVjxWM3x5V9eKnp4DATA@mail.gmail.com>
Message-ID: <CAH6Pt5p_sg4VSU2h5sGhjG8FEV5Hkd_GbabeZdo=mCgpOO6tPg@mail.gmail.com>

On Thu, Sep 15, 2016 at 12:07 PM, Francois Budin
<francois.budin at kitware.com> wrote:
> How about writing the book in a Jupyter notebook using a Python or a
> Javascript kernel to run the examples? I know it is possible to export the
> content of notebooks as PDFs through LaTeX, although I am not sure how the
> formatting is handled and if that would work for a book.

I've used notebooks a lot, but it's not a practical format for editing
a large document like a book.   For example, some colleagues of mine
who also use notebooks a lot developed their own markdown annotation
to be able to build and run the code examples from markdown text
files.  They can then export the document as notebooks, for them as
needs them.

Cheers,

Matthew

From david.gobbi at gmail.com  Thu Sep 15 17:02:44 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 15 Sep 2016 15:02:44 -0600
Subject: [vtk-developers] More funny vtktiff stuff
Message-ID: <CANwS1=HZzTq4_v6nZ78xHRzN7vZVAWqAAnE6BeVX=BZsy6Pz7w@mail.gmail.com>

The vtktiff module is producing a library called "libport".  My guess is
that it's yet another bit of tiff stuff that is irrelevant to VTK and can
be removed from the vtktiff build.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/2a99a7aa/attachment-0001.html>

From andrew.amaclean at gmail.com  Thu Sep 15 18:54:57 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 16 Sep 2016 08:54:57 +1000
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
Message-ID: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>

Nice.
Personally I think LaTex is the way to go. There is even a cross-platform
open source "GUI" called LyX http://www.lyx.org/Home which is available.
Aditionally, you can even use CMake to automate the process, see:
https://cmake.org/Wiki/CMakeUserUseLATEX

I should be able to help with the LaTex stuff.

Regards
    Andrew

---------- Forwarded message ----------
> From: Will Schroeder <will.schroeder at kitware.com>
> To: vtk-developers <vtk-developers at vtk.org>, vtkusers <vtkusers at vtk.org>
> Cc: ParaView Developers <paraview-developers at paraview.org>,
> insight-users at itk.org, insight-developers at itk.org, paraview at paraview.org
> Date: Thu, 15 Sep 2016 13:54:58 -0400
> Subject: [vtk-developers] VTK Textbook and User's Guide now available for
> download
> Kitware is releasing the VTK Textbook and VTK User's Guide for PDF
> download. Follow the links below to a landing page where you can buy a
> printed version, or download a PDF.
>
> Longer term, the plan is to convert these books to LaTeX (from Framemaker)
> and place the content into an open repository. The first step is to mostly
> duplicate what exists now; eventually we have the ambitious goal to
> completely rewrite / recombine / rethink the books. For example, using
> VTK.js (under development now) to offer web interaction with examples etc.
> We can certainly use the talents of the community to take this challenge
> on, so if you are interested please let me know.
>
> The Visualization Toolkit An Object-Oriented Approach to 3D Graphics (4th
> ed.)
> http://www.vtk.org/vtk-textbook/
> pdf: http://www.kitware.com/products/books/VTKTextbook.pdf
>
> *The VTK User?s Guide*
> http://www.vtk.org/vtk-users-guide/
> pdf: http://www.kitware.com/products/books/VTKUsersGuide.pdf
>
> Best, please let me know if there are issues or concerns.
> W
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
>
>

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/f9f917a3/attachment.html>

From david.gobbi at gmail.com  Thu Sep 15 19:14:51 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 15 Sep 2016 17:14:51 -0600
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
In-Reply-To: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
References: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
Message-ID: <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>

The best way to ensure broad collaboration on the textbook is to wikify
it.  After all, this is exactly what wikis were designed for: they make it
easy to track changes, they provide discussion space that's directly linked
to the content, there's a low barrier to entry, no big files to download,
etc.

I know that wiki collaboration doesn't always work out as planned, but
that's not a failure of the technology, it's a people issue and other
technology wouldn't do better.

 - David

On Thu, Sep 15, 2016 at 4:54 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> Nice.
> Personally I think LaTex is the way to go. There is even a cross-platform
> open source "GUI" called LyX http://www.lyx.org/Home which is available.
> Aditionally, you can even use CMake to automate the process, see:
> https://cmake.org/Wiki/CMakeUserUseLATEX
>
> I should be able to help with the LaTex stuff.
>
> Regards
>     Andrew
>
> ---------- Forwarded message ----------
>> From: Will Schroeder <will.schroeder at kitware.com>
>> To: vtk-developers <vtk-developers at vtk.org>, vtkusers <vtkusers at vtk.org>
>> Cc: ParaView Developers <paraview-developers at paraview.org>,
>> insight-users at itk.org, insight-developers at itk.org, paraview at paraview.org
>> Date: Thu, 15 Sep 2016 13:54:58 -0400
>> Subject: [vtk-developers] VTK Textbook and User's Guide now available for
>> download
>> Kitware is releasing the VTK Textbook and VTK User's Guide for PDF
>> download. Follow the links below to a landing page where you can buy a
>> printed version, or download a PDF.
>>
>> Longer term, the plan is to convert these books to LaTeX (from
>> Framemaker) and place the content into an open repository. The first step
>> is to mostly duplicate what exists now; eventually we have the ambitious
>> goal to completely rewrite / recombine / rethink the books. For example,
>> using VTK.js (under development now) to offer web interaction with examples
>> etc. We can certainly use the talents of the community to take this
>> challenge on, so if you are interested please let me know.
>>
>> The Visualization Toolkit An Object-Oriented Approach to 3D Graphics (4th
>> ed.)
>> http://www.vtk.org/vtk-textbook/
>> pdf: http://www.kitware.com/products/books/VTKTextbook.pdf
>>
>> *The VTK User?s Guide*
>> http://www.vtk.org/vtk-users-guide/
>> pdf: http://www.kitware.com/products/books/VTKUsersGuide.pdf
>>
>> Best, please let me know if there are issues or concerns.
>> W
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160915/9cddf4ae/attachment.html>

From matthew.brett at gmail.com  Thu Sep 15 19:17:39 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 15 Sep 2016 16:17:39 -0700
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
In-Reply-To: <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>
References: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
 <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>
Message-ID: <CAH6Pt5qmZMAOBbYDC8dgYFKfRhpEY6TiOZspFeB1b+-S8tTH-A@mail.gmail.com>

On Thu, Sep 15, 2016 at 4:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The best way to ensure broad collaboration on the textbook is to wikify it.
> After all, this is exactly what wikis were designed for: they make it easy
> to track changes, they provide discussion space that's directly linked to
> the content, there's a low barrier to entry, no big files to download, etc.
>
> I know that wiki collaboration doesn't always work out as planned, but
> that's not a failure of the technology, it's a people issue and other
> technology wouldn't do better.

Over at scipy, we used to have a wiki for docs, but it got pretty
stale, so we switched our docs over to a repo on github, so it is
easier to review changes.

Cheers,

Matthew

From marcus.hanwell at kitware.com  Fri Sep 16 09:59:02 2016
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Fri, 16 Sep 2016 09:59:02 -0400
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
In-Reply-To: <CAH6Pt5qmZMAOBbYDC8dgYFKfRhpEY6TiOZspFeB1b+-S8tTH-A@mail.gmail.com>
References: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
 <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>
 <CAH6Pt5qmZMAOBbYDC8dgYFKfRhpEY6TiOZspFeB1b+-S8tTH-A@mail.gmail.com>
Message-ID: <CAMkPkZWfZwX4U20ff8VvbQfbS=F4zuizuPCo0_5xQb9RPR8=Ew@mail.gmail.com>

On Thu, Sep 15, 2016 at 7:17 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>
> On Thu, Sep 15, 2016 at 4:14 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> > The best way to ensure broad collaboration on the textbook is to wikify it.
> > After all, this is exactly what wikis were designed for: they make it easy
> > to track changes, they provide discussion space that's directly linked to
> > the content, there's a low barrier to entry, no big files to download, etc.
> >
> > I know that wiki collaboration doesn't always work out as planned, but
> > that's not a failure of the technology, it's a people issue and other
> > technology wouldn't do better.
>
> Over at scipy, we used to have a wiki for docs, but it got pretty
> stale, so we switched our docs over to a repo on github, so it is
> easier to review changes.
>
I have also seen many wiki efforts go stale, but seen some pretty
successful git repositories using LaTex, Markdown and other formats. I
feel like LaTeX is a good option, and you can include code fragments
with highlighting etc, opening up the possibility of augmenting the
repository to test the code fragments used.

From utkarsh.ayachit at kitware.com  Fri Sep 16 10:06:12 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Fri, 16 Sep 2016 10:06:12 -0400
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
In-Reply-To: <CAMkPkZWfZwX4U20ff8VvbQfbS=F4zuizuPCo0_5xQb9RPR8=Ew@mail.gmail.com>
References: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
 <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>
 <CAH6Pt5qmZMAOBbYDC8dgYFKfRhpEY6TiOZspFeB1b+-S8tTH-A@mail.gmail.com>
 <CAMkPkZWfZwX4U20ff8VvbQfbS=F4zuizuPCo0_5xQb9RPR8=Ew@mail.gmail.com>
Message-ID: <CADHSJjBAe-aAKmTCPX4t5k-Yb3LM-N-az0L0MZDXWVXTxKJfmQ@mail.gmail.com>

>> > I know that wiki collaboration doesn't always work out as planned, but
>> > that's not a failure of the technology, it's a people issue and other
>> > technology wouldn't do better.

Adding another example, we tried using Wiki as the way to generate the
ParaView Guide for a few years. It was of course fraught with issues
everyone else reported at the same time, it was really hard to get a
professional looking PDF from it that one could print or use. Since we
moved to using a Gitlab repo for LaTeX however, things have been much
better (I am sure same would be true for other formats e.g. Markdown).
Further more, it's easier to version it and make updates in
conjunction with ParaView changes.

From bill.lorensen at gmail.com  Fri Sep 16 10:23:31 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 16 Sep 2016 10:23:31 -0400
Subject: [vtk-developers] Valgrind is no longer green
Message-ID: <CADZJ4hMiNxMjyF88f6BgsXveBcYAk5FBhvr9MAKReEGK0P+s4A@mail.gmail.com>

Folks,

vtkFiltersExtractionCxx-TestExtractTimeSteps is leaking memory.

-- 
Unpaid intern in BillsBasement at noware dot com

From utkarsh.ayachit at kitware.com  Fri Sep 16 10:55:24 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Fri, 16 Sep 2016 10:55:24 -0400
Subject: [vtk-developers] Valgrind is no longer green
In-Reply-To: <CADZJ4hMiNxMjyF88f6BgsXveBcYAk5FBhvr9MAKReEGK0P+s4A@mail.gmail.com>
References: <CADZJ4hMiNxMjyF88f6BgsXveBcYAk5FBhvr9MAKReEGK0P+s4A@mail.gmail.com>
Message-ID: <CADHSJjAAW=JGGiqLDT4o=TD9QYRjW7yK=UufJnnvjruAaOy+qg@mail.gmail.com>

Thanks for pointing it out, Bill. Here's a fix:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1962

On Fri, Sep 16, 2016 at 10:23 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Folks,
>
> vtkFiltersExtractionCxx-TestExtractTimeSteps is leaking memory.
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>

From will.schroeder at kitware.com  Fri Sep 16 12:27:32 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Fri, 16 Sep 2016 12:27:32 -0400
Subject: [vtk-developers] VTK Textbook and User's Guide now available
	for download
In-Reply-To: <CADHSJjBAe-aAKmTCPX4t5k-Yb3LM-N-az0L0MZDXWVXTxKJfmQ@mail.gmail.com>
References: <CAHDsG9N62MK3ejcL1kROQWjebHfQHoOhDC9efSSfhR_M9QgXZw@mail.gmail.com>
 <CANwS1=H3fCSt8qof4OK7LSsDGAPHPZPPzzzK4+6Gv5vnp_cxrQ@mail.gmail.com>
 <CAH6Pt5qmZMAOBbYDC8dgYFKfRhpEY6TiOZspFeB1b+-S8tTH-A@mail.gmail.com>
 <CAMkPkZWfZwX4U20ff8VvbQfbS=F4zuizuPCo0_5xQb9RPR8=Ew@mail.gmail.com>
 <CADHSJjBAe-aAKmTCPX4t5k-Yb3LM-N-az0L0MZDXWVXTxKJfmQ@mail.gmail.com>
Message-ID: <CAEiDrtW+n+jrY50zUK=6h2P-5JXGF8XxStAk3Y=FNpyBuo7rTA@mail.gmail.com>

Please remember that the textbook has a fair number of fancy equations.
LaTeX certainly handles equations well....if we were to consider other
alternatives I'd consider this a hard requirement.


On Fri, Sep 16, 2016 at 10:06 AM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> >> > I know that wiki collaboration doesn't always work out as planned, but
> >> > that's not a failure of the technology, it's a people issue and other
> >> > technology wouldn't do better.
>
> Adding another example, we tried using Wiki as the way to generate the
> ParaView Guide for a few years. It was of course fraught with issues
> everyone else reported at the same time, it was really hard to get a
> professional looking PDF from it that one could print or use. Since we
> moved to using a Gitlab repo for LaTeX however, things have been much
> better (I am sure same would be true for other formats e.g. Markdown).
> Further more, it's easier to version it and make updates in
> conjunction with ParaView changes.
>



-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/0511d6e8/attachment.html>

From sean at rogue-research.com  Fri Sep 16 13:13:52 2016
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 16 Sep 2016 13:13:52 -0400
Subject: [vtk-developers] Nightly failures
In-Reply-To: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
Message-ID: <20160916171352.2077783761@mail.rogue-research.com>

On Thu, 15 Sep 2016 13:38:51 -0400, Berk Geveci said:

>Two nightly dashboards are failing with the Tcl error below. Can whoever
>caused this failure look into it?

Similarly, someone introduced two new cppcheck warnings the other day:

<https://open.cdash.org/viewBuildError.php?type=1&buildid=4552302>

1) Filters/Core/Testing/Cxx/TestAssignAttribute.cxx:170: style: Same expression on both sides of '||'.

2) Imaging/Morphological/vtkImageConnectivityFilter.cxx:396: performance: Function parameter 'seed' should be passed by reference.

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 dave.demarle at kitware.com  Fri Sep 16 14:41:10 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 16 Sep 2016 14:41:10 -0400
Subject: [vtk-developers] poll - vtk doxygen style
Message-ID: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>

Hey Folks,

I'm getting ready to replace VTK's non-standard documentation comment style
with normal doxygen markup. Once we do that IDEs will generally do the
right thing and we can all more easily edit the headers and get exactly
what we expect.

Before I make the big initial conversion commit, what specific doxygen
flavor do people prefer?

/*! and //! vs /** and ///
all c-style (/*) or all c++ style (//) or mixed OK?
for c-style, leading *'s or not in continuation lines

thanks

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/3fefb48d/attachment.html>

From dave.demarle at kitware.com  Fri Sep 16 14:45:58 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 16 Sep 2016 14:45:58 -0400
Subject: [vtk-developers] ready to branch for 7.1?
Message-ID: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>

Does anyone out that have partially completed work in progress that we
should delay the release branch point for?

We are hoping to get 7.1 started in a day or two.

thanks,

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/5c770777/attachment.html>

From utkarsh.ayachit at kitware.com  Fri Sep 16 14:49:36 2016
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Fri, 16 Sep 2016 14:49:36 -0400
Subject: [vtk-developers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
Message-ID: <CADHSJjCLsacDfMHTKB2W73k6KybpczN5d5xu9hGbZ51S=eWcsg@mail.gmail.com>

///   get's my vote



On Fri, Sep 16, 2016 at 2:41 PM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> Hey Folks,
>
> I'm getting ready to replace VTK's non-standard documentation comment style
> with normal doxygen markup. Once we do that IDEs will generally do the right
> thing and we can all more easily edit the headers and get exactly what we
> expect.
>
> Before I make the big initial conversion commit, what specific doxygen
> flavor do people prefer?
>
> /*! and //! vs /** and ///
> all c-style (/*) or all c++ style (//) or mixed OK?
> for c-style, leading *'s or not in continuation lines
>
> thanks
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From alvaro.sanchez at kitware.com  Fri Sep 16 14:50:12 2016
From: alvaro.sanchez at kitware.com (Alvaro Sanchez)
Date: Fri, 16 Sep 2016 14:50:12 -0400
Subject: [vtk-developers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
Message-ID: <CADM17uPWifSOREu+TUmhXZE=quMvo0sMjcch5s=NOAwYVMSnJQ@mail.gmail.com>

I personally prefer ///,  no specific reason.  Would be good to stick to a
single one though.


On Fri, Sep 16, 2016 at 2:41 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Hey Folks,
>
> I'm getting ready to replace VTK's non-standard documentation comment
> style with normal doxygen markup. Once we do that IDEs will generally do
> the right thing and we can all more easily edit the headers and get exactly
> what we expect.
>
> Before I make the big initial conversion commit, what specific doxygen
> flavor do people prefer?
>
> /*! and //! vs /** and ///
> all c-style (/*) or all c++ style (//) or mixed OK?
> for c-style, leading *'s or not in continuation lines
>
> thanks
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Alvaro Sanchez
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/beff3f40/attachment.html>

From elvis.stansvik at orexplore.com  Fri Sep 16 15:06:32 2016
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 16 Sep 2016 21:06:32 +0200
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
Message-ID: <CAE-7VJkeohydZubxrqfZDuPO2OLXQqaKPisJ1gr3r4xfPO2q5A@mail.gmail.com>

Den 16 sep. 2016 8:46 em skrev "David E DeMarle" <dave.demarle at kitware.com>:

>

> Does anyone out that have partially completed work in progress that we
should delay the release branch point for?
>
> We are hoping to get 7.1 started in a day or two.

Wow that's sooner than I thought. Sorry for the noise, but as a user
standing by the sidelines: Many thanks to all the contributors!

Elvis

>
> thanks,
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/11ef946d/attachment-0001.html>

From haocheng.liu at kitware.com  Fri Sep 16 15:19:24 2016
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Fri, 16 Sep 2016 15:19:24 -0400
Subject: [vtk-developers] Nightly failures
In-Reply-To: <20160916171352.2077783761@mail.rogue-research.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
 <20160916171352.2077783761@mail.rogue-research.com>
Message-ID: <CACbTE7OSGoLWTmr-6XAT5tEE6YaWeup1YKUVsZFxLkQ=xUPGTg@mail.gmail.com>

MR for nightly dashboards failure.
https://gitlab.kitware.com/vtk/vtk/merge_requests/1965. A weird and
hard-to-find bug, but it works on my local test.... Let's wait for the
dashboard  and nightly dashboard results
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/b51f459a/attachment.html>

From david.lonie at kitware.com  Fri Sep 16 15:26:51 2016
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 16 Sep 2016 15:26:51 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
Message-ID: <CA+=e1ovqSLqA5bDzb2SMvmbctVeGFnBR+3aWoi-qxhfWdjJ7=A@mail.gmail.com>

My FXAA branch should be ready to merge soon. I'll try to get it in by
Monday.

On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Does anyone out that have partially completed work in progress that we
> should delay the release branch point for?
>
> We are hoping to get 7.1 started in a day or two.
>
> thanks,
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/3e39e4c4/attachment.html>

From cory.quammen at kitware.com  Fri Sep 16 15:49:32 2016
From: cory.quammen at kitware.com (Cory Quammen)
Date: Fri, 16 Sep 2016 15:49:32 -0400
Subject: [vtk-developers] Nightly failures
In-Reply-To: <CACbTE7OSGoLWTmr-6XAT5tEE6YaWeup1YKUVsZFxLkQ=xUPGTg@mail.gmail.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
 <20160916171352.2077783761@mail.rogue-research.com>
 <CACbTE7OSGoLWTmr-6XAT5tEE6YaWeup1YKUVsZFxLkQ=xUPGTg@mail.gmail.com>
Message-ID: <CAB5Fpx4EVqtmmBRTzGNtg8Ng62AGyK6CAzjU3oCZnrm5zZ=e2w@mail.gmail.com>

I'm working on the the problem with TestAssignAttribute.cxx and ran
into another issue with a module dependency cycle introduced by the
changes to the modules.cmake file. Some modules have been added to
PRIVATE_DEPENDS erroneously.

I will post merge requests shortly.

On Fri, Sep 16, 2016 at 3:19 PM, Haocheng Liu <haocheng.liu at kitware.com> wrote:
> MR for nightly dashboards failure.
> https://gitlab.kitware.com/vtk/vtk/merge_requests/1965. A weird and
> hard-to-find bug, but it works on my local test.... Let's wait for the
> dashboard  and nightly dashboard results
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.

From karsten.tausche at student.hpi.uni-potsdam.de  Fri Sep 16 15:41:03 2016
From: karsten.tausche at student.hpi.uni-potsdam.de (Karsten Tausche)
Date: Fri, 16 Sep 2016 21:41:03 +0200
Subject: [vtk-developers] Nightly failures
In-Reply-To: <20160916171352.2077783761@mail.rogue-research.com>
References: <CAE32kpWXDo00rspJeDO7R8_7ikUHNWYqXUZ_dh2Qj58ga3U2xg@mail.gmail.com>
 <20160916171352.2077783761@mail.rogue-research.com>
Message-ID: <35b0589a-2673-8b5e-6b77-3e28223165d5@student.hpi.uni-potsdam.de>

I pushed a fix for the cppcheck warning I introduced:
https://gitlab.kitware.com/vtk/vtk/merge_requests/1966

Cheers,
Karsten

On 2016-09-16 19:13, Sean McBride wrote:
> <https://open.cdash.org/viewBuildError.php?type=1&buildid=4552302>
>
> 1) Filters/Core/Testing/Cxx/TestAssignAttribute.cxx:170: style: Same expression on both sides of '||'.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/548b52b4/attachment.html>

From david.lonie at kitware.com  Fri Sep 16 15:55:33 2016
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 16 Sep 2016 15:55:33 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CA+=e1ovqSLqA5bDzb2SMvmbctVeGFnBR+3aWoi-qxhfWdjJ7=A@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
 <CA+=e1ovqSLqA5bDzb2SMvmbctVeGFnBR+3aWoi-qxhfWdjJ7=A@mail.gmail.com>
Message-ID: <CA+=e1ou8iJ-aqQNreV_uDt_w2iqG6JxQLKi=qhwvZZbaP_jQzQ@mail.gmail.com>

Oh, and we should probably fix the vtkDebugLeaks/VTK_ALL_OBJECT_FACTORY_NEW
stuff before the branch, too:

https://gitlab.kitware.com/vtk/vtk/issues/16850

I'll patch that early next week.

On Fri, Sep 16, 2016 at 3:26 PM, David Lonie <david.lonie at kitware.com>
wrote:

> My FXAA branch should be ready to merge soon. I'll try to get it in by
> Monday.
>
> On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> Does anyone out that have partially completed work in progress that we
>> should delay the release branch point for?
>>
>> We are hoping to get 7.1 started in a day or two.
>>
>> thanks,
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/c0415c9a/attachment.html>

From joseph.g.hennessey2.ctr at mail.mil  Fri Sep 16 16:39:39 2016
From: joseph.g.hennessey2.ctr at mail.mil (Hennessey, Joseph G CTR USARMY RDECOM ARL (US))
Date: Fri, 16 Sep 2016 20:39:39 +0000
Subject: [vtk-developers] [Non-DoD Source] ready to branch for 7.1?
 (UNCLASSIFIED)
Message-ID: <10A03274360DCF47A6EE78C9952A31CA87D8B12B@UMECHPA7C.easf.csd.disa.mil>

CLASSIFICATION: UNCLASSIFIED

David,

Have you accepted my Xdmf merge request?

Merge Request !1886

I would like that to be in there, it has the latest changes to the Xdmf
library,

As well as my updated reader/writer for VTK and a new parallel writer for VTK.

Thanks,

Joe

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joseph G. Hennessey Ph.D., Leidos
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Email:  joseph.g.hennessey2.ctr at mail.mil


-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
David E DeMarle
Sent: Friday, September 16, 2016 2:46 PM
To: vtkdev <vtk-developers at vtk.org>
Cc: Elvis Stansvik <elvis.stansvik at orexplore.com>
Subject: [Non-DoD Source] [vtk-developers] ready to branch for 7.1?

Does anyone out that have partially completed work in progress that we should
delay the release branch point for?

We are hoping to get 7.1 started in a day or two.

thanks,


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909


CLASSIFICATION: UNCLASSIFIED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5615 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/3fa4ce90/attachment-0001.bin>

From sean at rogue-research.com  Fri Sep 16 17:31:37 2016
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 16 Sep 2016 17:31:37 -0400
Subject: [vtk-developers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
Message-ID: <20160916213137.492003816@mail.rogue-research.com>

On Fri, 16 Sep 2016 14:41:10 -0400, David E DeMarle said:

>Before I make the big initial conversion commit, what specific doxygen
>flavor do people prefer?

I prefer /// and /** */, like:

	/// Summary blah blah
	/** Details blah blah. */
	int Function(int param)

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From ken.martin at kitware.com  Fri Sep 16 19:18:06 2016
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 16 Sep 2016 19:18:06 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
Message-ID: <CANXz0SasqpjV=sYWGRBT8wUnspHqpKF73fEwm7UPGJs_e5Tc9g@mail.gmail.com>

I have two topics I would like to get merged both are "close" but they are
not tiny topics.

Put in a better framework for releasing graphics resources

  https://gitlab.kitware.com/vtk/vtk/merge_requests/1953

and rework the OpenGL2 compositepolydatamapper2 so there are no slow paths

  https://gitlab.kitware.com/vtk/vtk/merge_requests/1909




On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Does anyone out that have partially completed work in progress that we
> should delay the release branch point for?
>
> We are hoping to get 7.1 started in a day or two.
>
> thanks,
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160916/c2416fdc/attachment.html>

From will.schroeder at kitware.com  Sat Sep 17 06:43:35 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Sat, 17 Sep 2016 06:43:35 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
Message-ID: <CAEiDrtWQ6NVc3USjhMR1hROZcRnTO=vO9tDm6Fvao9Pp9kRG2A@mail.gmail.com>

I have two MRs pending: 1) a small one (with Cory) for a nice quadric
decimation addition contributed by Louis Bergmann; 2) a larger one about 30
files which moves the vtkPointCloud classes into Filters/Points. I think I
can get these pushed on Monday barring unforeseen stuff, etc. It'll
probably take a day or two to move through the testing process.

On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Does anyone out that have partially completed work in progress that we
> should delay the release branch point for?
>
> We are hoping to get 7.1 started in a day or two.
>
> thanks,
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/5ebf7112/attachment.html>

From berk.geveci at kitware.com  Sat Sep 17 09:02:35 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Sat, 17 Sep 2016 09:02:35 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CAEiDrtWQ6NVc3USjhMR1hROZcRnTO=vO9tDm6Fvao9Pp9kRG2A@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
 <CAEiDrtWQ6NVc3USjhMR1hROZcRnTO=vO9tDm6Fvao9Pp9kRG2A@mail.gmail.com>
Message-ID: <CAE32kpWn=2XzF_0dV6Dg7RHJK6+Z_JmoFDDgkBC0UHs06dm-Fw@mail.gmail.com>

This reminds me of old gold-rush releases where everybody is trying to
squeeze in a large feature :-)

If it helps folks make timing decisions, we plan on having VTK 8 in
January-February 2017. So if necessary some of the bigger topics could
probably be post-7.1.

-berk

On Sat, Sep 17, 2016 at 6:43 AM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> I have two MRs pending: 1) a small one (with Cory) for a nice quadric
> decimation addition contributed by Louis Bergmann; 2) a larger one about 30
> files which moves the vtkPointCloud classes into Filters/Points. I think I
> can get these pushed on Monday barring unforeseen stuff, etc. It'll
> probably take a day or two to move through the testing process.
>
> On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> Does anyone out that have partially completed work in progress that we
>> should delay the release branch point for?
>>
>> We are hoping to get 7.1 started in a day or two.
>>
>> thanks,
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/01eb68fe/attachment.html>

From will.schroeder at kitware.com  Sat Sep 17 09:24:23 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Sat, 17 Sep 2016 09:24:23 -0400
Subject: [vtk-developers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
Message-ID: <CAEiDrtWr4EQk5xss21VGRhZmoCMEaNxQvZ=8jMRVF8bafDc9OA@mail.gmail.com>

For reference, I believe ITK uses /** text */

  /** Method for creation through the object factory. */

and

  /** A global data type for this class of equations.  Used to store
   * values that are needed in calculating the time step and other
intermediate
   * products such as derivatives that may be used by virtual functions
called
   * from ComputeUpdate.  Caching these values here allows the ComputeUpdate
   * function to be const and thread safe. */



On Fri, Sep 16, 2016 at 2:41 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Hey Folks,
>
> I'm getting ready to replace VTK's non-standard documentation comment
> style with normal doxygen markup. Once we do that IDEs will generally do
> the right thing and we can all more easily edit the headers and get exactly
> what we expect.
>
> Before I make the big initial conversion commit, what specific doxygen
> flavor do people prefer?
>
> /*! and //! vs /** and ///
> all c-style (/*) or all c++ style (//) or mixed OK?
> for c-style, leading *'s or not in continuation lines
>
> thanks
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>


-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/b0bac86f/attachment-0001.html>

From DLRdave at aol.com  Sat Sep 17 10:24:03 2016
From: DLRdave at aol.com (David Cole)
Date: Sat, 17 Sep 2016 10:24:03 -0400
Subject: [vtk-developers] [vtkusers]  poll - vtk doxygen style
In-Reply-To: <CAEiDrtWr4EQk5xss21VGRhZmoCMEaNxQvZ=8jMRVF8bafDc9OA@mail.gmail.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
 <CAEiDrtWr4EQk5xss21VGRhZmoCMEaNxQvZ=8jMRVF8bafDc9OA@mail.gmail.com>
Message-ID: <A377D027-7EA2-47EC-A118-37CB708282A1@aol.com>

For what it's worth, I've always found reading the /// style throughout to be the easiest on my brain and eyes when reading in a text editor. For some reason, it seems to be easiest to filter out a constant column of /// repeated on every line than the sprinkled start/stop signals of the other styles.

Just my 2 cents,
David C.


> On Sep 17, 2016, at 9:24 AM, Will Schroeder <will.schroeder at kitware.com> wrote:
> 
> For reference, I believe ITK uses /** text */
> 
>   /** Method for creation through the object factory. */
> 
> and
> 
>   /** A global data type for this class of equations.  Used to store
>    * values that are needed in calculating the time step and other intermediate
>    * products such as derivatives that may be used by virtual functions called
>    * from ComputeUpdate.  Caching these values here allows the ComputeUpdate
>    * function to be const and thread safe. */
> 
> 
> 
>> On Fri, Sep 16, 2016 at 2:41 PM, David E DeMarle <dave.demarle at kitware.com> wrote:
>> Hey Folks,
>> 
>> I'm getting ready to replace VTK's non-standard documentation comment style with normal doxygen markup. Once we do that IDEs will generally do the right thing and we can all more easily edit the headers and get exactly what we expect.
>> 
>> Before I make the big initial conversion commit, what specific doxygen flavor do people prefer?
>> 
>> /*! and //! vs /** and /// 
>> all c-style (/*) or all c++ style (//) or mixed OK?
>> for c-style, leading *'s or not in continuation lines
>> 
>> thanks
>> 
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
> 
> 
> 
> -- 
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> 
> Search the list archives at: http://markmail.org/search/?q=vtkusers
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/f60d96f6/attachment.html>

From david.thompson at kitware.com  Sat Sep 17 11:01:44 2016
From: david.thompson at kitware.com (David Thompson)
Date: Sat, 17 Sep 2016 11:01:44 -0400
Subject: [vtk-developers] [vtkusers]  poll - vtk doxygen style
In-Reply-To: <A377D027-7EA2-47EC-A118-37CB708282A1@aol.com>
References: <CANjZAi8TLay_aDjfQMMUxUT_MeTF_bxsz4ZhbkK_riMOvkuGkA@mail.gmail.com>
 <CAEiDrtWr4EQk5xss21VGRhZmoCMEaNxQvZ=8jMRVF8bafDc9OA@mail.gmail.com>
 <A377D027-7EA2-47EC-A118-37CB708282A1@aol.com>
Message-ID: <18D50BCB-9BB9-479C-9B9B-9009E9E637F8@kitware.com>

I like the /** ... */ style comments with an explicit \brief keyword where warranted.

I also strongly advocate putting documentation wherever the implementation is, rather than the declaration, on the principal that people who change the implementation will be more likely to update the docs that way.

    David

> On Sep 17, 2016, at 10:24, David Cole via vtk-developers <vtk-developers at vtk.org> wrote:
> 
> For what it's worth, I've always found reading the /// style throughout to be the easiest on my brain and eyes when reading in a text editor. For some reason, it seems to be easiest to filter out a constant column of /// repeated on every line than the sprinkled start/stop signals of the other styles.
> 
> Just my 2 cents,
> David C.
> 
> 
>> On Sep 17, 2016, at 9:24 AM, Will Schroeder <will.schroeder at kitware.com> wrote:
>> 
>> For reference, I believe ITK uses /** text */
>> 
>>   /** Method for creation through the object factory. */
>> 
>> and
>> 
>>   /** A global data type for this class of equations.  Used to store
>>    * values that are needed in calculating the time step and other intermediate
>>    * products such as derivatives that may be used by virtual functions called
>>    * from ComputeUpdate.  Caching these values here allows the ComputeUpdate
>>    * function to be const and thread safe. */
>> 
>> 
>> 
>>> On Fri, Sep 16, 2016 at 2:41 PM, David E DeMarle <dave.demarle at kitware.com> wrote:
>>> Hey Folks,
>>> 
>>> I'm getting ready to replace VTK's non-standard documentation comment style with normal doxygen markup. Once we do that IDEs will generally do the right thing and we can all more easily edit the headers and get exactly what we expect.
>>> 
>>> Before I make the big initial conversion commit, what specific doxygen flavor do people prefer?
>>> 
>>> /*! and //! vs /** and /// 
>>> all c-style (/*) or all c++ style (//) or mixed OK?
>>> for c-style, leading *'s or not in continuation lines
>>> 
>>> thanks
>>> 
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>> 
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>> 
>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> William J. Schroeder, PhD
>> Kitware, Inc. - Building the World's Technical Computing Software
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>> 
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/316b4f85/attachment.html>

From andrew.amaclean at gmail.com  Sat Sep 17 18:31:01 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 18 Sep 2016 08:31:01 +1000
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
Message-ID: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>

In looking through all my code, I have settled on two styles A, and B
(often used interchangeably). See also the variant of style B tha I use for
the class description.

Personally I would favour style B without the asterisks in front of every
line i.e the one I use for the class description.
The reasons for this are:
 1. When writing cross-platform code, especially Python, it is very easy to
convert this style to the one favoured by Sphinx. Java, on the other hand,
tends to prefer the leading asterisk.
 2. It looks clean and is easy to read.

For what it is worth, I also believe that documentation should be with the
declaration simply because the header files are the ones people tend to
first look at not the definition. This is what VTK currently does.


A:
      //! Test for a leap year.
      /*!
        * @param year Year
        * @param calendar The calendar to use.
        * @return true if it is a leap year.
        */

or B:

      /**
      * Calculate the Julian day number of the date.
      * The Proleptic Gregorian Calendar is used.
      *
      * Not valid for ymd < -4713 12 25.

      * @param ymd The year, month and day.
      *
      * @return The Julian day number of the date, an integer
      *  running from noon to noon.
      */

For a class description I use this, style B with no asterisks in front of
every line:
  /**
    This class provides conversion routines between Calendrical dates and
     times and the date and time as a Julian Day Number (JDN) and fraction
     of the day (FoD).

    The Julian Day is defined as the interval of time in days and fractions
of
     a day since 4713 B.C. January 1, Greenwich noon Julian proleptic
calendar.
    ... more stuff ...
    */

See: https://gitlab.com/amaclean/date-time in this, there are C++, Python
and Java implementations of the same code.

Regards
   Andrew
-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160918/06fa8765/attachment.html>

From david.thompson at kitware.com  Sat Sep 17 18:47:44 2016
From: david.thompson at kitware.com (David Thompson)
Date: Sat, 17 Sep 2016 18:47:44 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
Message-ID: <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>

Hi Andrew,

> ...
> For what it is worth, I also believe that documentation should be with the declaration simply because the header files are the ones people tend to first look at not the definition. This is what VTK currently does. ...

I think that moving method (not class) documentation out of the headers makes the headers much more terse and legible. For the vast majority of classes, the method names themselves are enough documentation. In cases where method names are not enough, it is nice to have the implementation nearby. Methods with inline or macro-generated implementations would still have documentation in the header, as would enums.

    David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/52e9d974/attachment.html>

From DLRdave at aol.com  Sat Sep 17 22:37:29 2016
From: DLRdave at aol.com (David Cole)
Date: Sat, 17 Sep 2016 22:37:29 -0400
Subject: [vtk-developers] [vtkusers]   poll - vtk doxygen style
In-Reply-To: <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
Message-ID: <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>

Another argument for keeping all documentation in the header files is so it's available in an install-tree-only situation. Some people use VTK without the source tree around, and having the docs built into the header files is quite nice in that scenario. If it were in the cxx files, it wouldn't be available to such users.


David


> On Sep 17, 2016, at 6:47 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi Andrew,
> 
> ...
>> For what it is worth, I also believe that documentation should be with the declaration simply because the header files are the ones people tend to first look at not the definition. This is what VTK currently does. ...
> 
> I think that moving method (not class) documentation out of the headers makes the headers much more terse and legible. For the vast majority of classes, the method names themselves are enough documentation. In cases where method names are not enough, it is nice to have the implementation nearby. Methods with inline or macro-generated implementations would still have documentation in the header, as would enums.
> 
>     David
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
> 
> Search the list archives at: http://markmail.org/search/?q=vtkusers
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160917/d12b87e8/attachment.html>

From david.thompson at kitware.com  Sun Sep 18 09:31:23 2016
From: david.thompson at kitware.com (David Thompson)
Date: Sun, 18 Sep 2016 09:31:23 -0400
Subject: [vtk-developers] [vtkusers]   poll - vtk doxygen style
In-Reply-To: <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
Message-ID: <830CFB38-1FF6-4EE0-A1F6-569380BDFF88@kitware.com>

But an install tree will have doxygen's output in it.

    David

> On Sep 17, 2016, at 22:37, David Cole <DLRdave at aol.com> wrote:
> 
> Another argument for keeping all documentation in the header files is so it's available in an install-tree-only situation. Some people use VTK without the source tree around, and having the docs built into the header files is quite nice in that scenario. If it were in the cxx files, it wouldn't be available to such users.
> 
> 
> David
> 
> 
>> On Sep 17, 2016, at 6:47 PM, David Thompson <david.thompson at kitware.com> wrote:
>> 
>> Hi Andrew,
>> 
>> ...
>>> For what it is worth, I also believe that documentation should be with the declaration simply because the header files are the ones people tend to first look at not the definition. This is what VTK currently does. ...
>> 
>> I think that moving method (not class) documentation out of the headers makes the headers much more terse and legible. For the vast majority of classes, the method names themselves are enough documentation. In cases where method names are not enough, it is nice to have the implementation nearby. Methods with inline or macro-generated implementations would still have documentation in the header, as would enums.
>> 
>>     David
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>> 
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160918/c8d4f989/attachment.html>

From ben.boeckel at kitware.com  Sun Sep 18 11:06:02 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Sun, 18 Sep 2016 11:06:02 -0400
Subject: [vtk-developers] [vtkusers]   poll - vtk doxygen style
In-Reply-To: <830CFB38-1FF6-4EE0-A1F6-569380BDFF88@kitware.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <830CFB38-1FF6-4EE0-A1F6-569380BDFF88@kitware.com>
Message-ID: <20160918150602.GA10210@megas.kitware.com>

On Sun, Sep 18, 2016 at 09:31:23 -0400, David Thompson wrote:
> But an install tree will have doxygen's output in it.

Assuming Doxygen was available during the build? There's nothing in VTK
that pressures people to enable documentation, so not building it is
easy.

--Ben

From marcus.hanwell at kitware.com  Mon Sep 19 08:56:02 2016
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 19 Sep 2016 08:56:02 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
Message-ID: <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>

The Doxygen isn't always there, when I am hunting issues I often end
up in the header for the class thanks to my IDE, and having the
Doxygen there is often helpful whether the Doxygen is somewhere on the
machine or not. I really dislike projects that put it in the
implementation, and disagree on the method names being enough. I hope
we leave it in the headers, and for the purposes of the migration to
real Doxygen I am not sure the tools have the necessary logic to move
documentation - just transform the style.

I prefer the

/**
 * Document code
 * @param
 */

Style personally, but /// also works, never really liked the //! but I
am sure I could adapt were that chosen.

On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
<vtk-developers at vtk.org> wrote:
> Another argument for keeping all documentation in the header files is so
> it's available in an install-tree-only situation. Some people use VTK
> without the source tree around, and having the docs built into the header
> files is quite nice in that scenario. If it were in the cxx files, it
> wouldn't be available to such users.
>
>
> David
>
>
> On Sep 17, 2016, at 6:47 PM, David Thompson <david.thompson at kitware.com>
> wrote:
>
> Hi Andrew,
>
> ...
>
> For what it is worth, I also believe that documentation should be with the
> declaration simply because the header files are the ones people tend to
> first look at not the definition. This is what VTK currently does. ...
>
>
> I think that moving method (not class) documentation out of the headers
> makes the headers much more terse and legible. For the vast majority of
> classes, the method names themselves are enough documentation. In cases
> where method names are not enough, it is nice to have the implementation
> nearby. Methods with inline or macro-generated implementations would still
> have documentation in the header, as would enums.
>
>     David
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From dan.lipsa at kitware.com  Mon Sep 19 09:40:21 2016
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Mon, 19 Sep 2016 09:40:21 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
Message-ID: <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>

I also prefer this doxygen style:

/**
 * Document code
 * @param
 */

as it creates a nice header for a function that contains the documentation.

I think documentation should stay in the header as it is part of the
interface of the module.




On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> The Doxygen isn't always there, when I am hunting issues I often end
> up in the header for the class thanks to my IDE, and having the
> Doxygen there is often helpful whether the Doxygen is somewhere on the
> machine or not. I really dislike projects that put it in the
> implementation, and disagree on the method names being enough. I hope
> we leave it in the headers, and for the purposes of the migration to
> real Doxygen I am not sure the tools have the necessary logic to move
> documentation - just transform the style.
>
> I prefer the
>
> /**
>  * Document code
>  * @param
>  */
>
> Style personally, but /// also works, never really liked the //! but I
> am sure I could adapt were that chosen.
>
> On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
> <vtk-developers at vtk.org> wrote:
> > Another argument for keeping all documentation in the header files is so
> > it's available in an install-tree-only situation. Some people use VTK
> > without the source tree around, and having the docs built into the header
> > files is quite nice in that scenario. If it were in the cxx files, it
> > wouldn't be available to such users.
> >
> >
> > David
> >
> >
> > On Sep 17, 2016, at 6:47 PM, David Thompson <david.thompson at kitware.com>
> > wrote:
> >
> > Hi Andrew,
> >
> > ...
> >
> > For what it is worth, I also believe that documentation should be with
> the
> > declaration simply because the header files are the ones people tend to
> > first look at not the definition. This is what VTK currently does. ...
> >
> >
> > I think that moving method (not class) documentation out of the headers
> > makes the headers much more terse and legible. For the vast majority of
> > classes, the method names themselves are enough documentation. In cases
> > where method names are not enough, it is nice to have the implementation
> > nearby. Methods with inline or macro-generated implementations would
> still
> > have documentation in the header, as would enums.
> >
> >     David
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at:
> > http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160919/44b4b970/attachment.html>

From robert.maynard at kitware.com  Mon Sep 19 10:16:12 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 19 Sep 2016 10:16:12 -0400
Subject: [vtk-developers] More funny vtktiff stuff
In-Reply-To: <CANwS1=HZzTq4_v6nZ78xHRzN7vZVAWqAAnE6BeVX=BZsy6Pz7w@mail.gmail.com>
References: <CANwS1=HZzTq4_v6nZ78xHRzN7vZVAWqAAnE6BeVX=BZsy6Pz7w@mail.gmail.com>
Message-ID: <CAFzjYVpDtszO_oQNUBmVywnDJw_2KOe3KkRCZ2u9xOWw1F2Now@mail.gmail.com>

I have rolled this into my tiff update MR.

On Thu, Sep 15, 2016 at 5:02 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The vtktiff module is producing a library called "libport".  My guess is
> that it's yet another bit of tiff stuff that is irrelevant to VTK and can be
> removed from the vtktiff build.
>
>  - David

From robert.maynard at kitware.com  Mon Sep 19 10:58:15 2016
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 19 Sep 2016 10:58:15 -0400
Subject: [vtk-developers] ready to branch for 7.1?
In-Reply-To: <CAE32kpWn=2XzF_0dV6Dg7RHJK6+Z_JmoFDDgkBC0UHs06dm-Fw@mail.gmail.com>
References: <CANjZAi9keRePB4U+eNAgbGFyRVBp=j4rWcqwbusJjwWKOEAfVg@mail.gmail.com>
 <CAEiDrtWQ6NVc3USjhMR1hROZcRnTO=vO9tDm6Fvao9Pp9kRG2A@mail.gmail.com>
 <CAE32kpWn=2XzF_0dV6Dg7RHJK6+Z_JmoFDDgkBC0UHs06dm-Fw@mail.gmail.com>
Message-ID: <CAFzjYVptB934tOHkyd=gP3F4a2KGV3fvdFqx=TH_TJJgKZzzmQ@mail.gmail.com>

I would like to get the Tiff cmake cache pollution fixes in for 7.1 (
https://gitlab.kitware.com/vtk/vtk/merge_requests/1926 )

Currently tiff is making a mess of the default ccmake/cmake-gui for vtk.

On Sat, Sep 17, 2016 at 9:02 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
> This reminds me of old gold-rush releases where everybody is trying to
> squeeze in a large feature :-)
>
> If it helps folks make timing decisions, we plan on having VTK 8 in
> January-February 2017. So if necessary some of the bigger topics could
> probably be post-7.1.
>
> -berk
>
> On Sat, Sep 17, 2016 at 6:43 AM, Will Schroeder <will.schroeder at kitware.com>
> wrote:
>>
>> I have two MRs pending: 1) a small one (with Cory) for a nice quadric
>> decimation addition contributed by Louis Bergmann; 2) a larger one about 30
>> files which moves the vtkPointCloud classes into Filters/Points. I think I
>> can get these pushed on Monday barring unforeseen stuff, etc. It'll probably
>> take a day or two to move through the testing process.
>>
>> On Fri, Sep 16, 2016 at 2:45 PM, David E DeMarle
>> <dave.demarle at kitware.com> wrote:
>>>
>>> Does anyone out that have partially completed work in progress that we
>>> should delay the release branch point for?
>>>
>>> We are hoping to get 7.1 started in a day or two.
>>>
>>> thanks,
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc. - Building the World's Technical Computing Software
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From david.lonie at kitware.com  Mon Sep 19 14:27:46 2016
From: david.lonie at kitware.com (David Lonie)
Date: Mon, 19 Sep 2016 14:27:46 -0400
Subject: [vtk-developers] [vtkusers]  poll - vtk doxygen style
In-Reply-To: <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
Message-ID: <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>

One more vote for /** ... */ with leading * on lines in-between, and
keeping the docs in the headers. Jumping to a header is much faster and
easier than opening a doxygen page with modern IDEs. Plus, I doubt anyone
would want to volunteer for the task of moving all the docstrings, and it
doesn't sound easy to script/automate.

On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com> wrote:

> I also prefer this doxygen style:
>
> /**
>  * Document code
>  * @param
>  */
>
> as it creates a nice header for a function that contains the documentation.
>
> I think documentation should stay in the header as it is part of the
> interface of the module.
>
>
>
>
> On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell <
> marcus.hanwell at kitware.com> wrote:
>
>> The Doxygen isn't always there, when I am hunting issues I often end
>> up in the header for the class thanks to my IDE, and having the
>> Doxygen there is often helpful whether the Doxygen is somewhere on the
>> machine or not. I really dislike projects that put it in the
>> implementation, and disagree on the method names being enough. I hope
>> we leave it in the headers, and for the purposes of the migration to
>> real Doxygen I am not sure the tools have the necessary logic to move
>> documentation - just transform the style.
>>
>> I prefer the
>>
>> /**
>>  * Document code
>>  * @param
>>  */
>>
>> Style personally, but /// also works, never really liked the //! but I
>> am sure I could adapt were that chosen.
>>
>> On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
>> <vtk-developers at vtk.org> wrote:
>> > Another argument for keeping all documentation in the header files is so
>> > it's available in an install-tree-only situation. Some people use VTK
>> > without the source tree around, and having the docs built into the
>> header
>> > files is quite nice in that scenario. If it were in the cxx files, it
>> > wouldn't be available to such users.
>> >
>> >
>> > David
>> >
>> >
>> > On Sep 17, 2016, at 6:47 PM, David Thompson <david.thompson at kitware.com
>> >
>> > wrote:
>> >
>> > Hi Andrew,
>> >
>> > ...
>> >
>> > For what it is worth, I also believe that documentation should be with
>> the
>> > declaration simply because the header files are the ones people tend to
>> > first look at not the definition. This is what VTK currently does. ...
>> >
>> >
>> > I think that moving method (not class) documentation out of the headers
>> > makes the headers much more terse and legible. For the vast majority of
>> > classes, the method names themselves are enough documentation. In cases
>> > where method names are not enough, it is nice to have the implementation
>> > nearby. Methods with inline or macro-generated implementations would
>> still
>> > have documentation in the header, as would enums.
>> >
>> >     David
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the VTK FAQ at:
>> > http://www.vtk.org/Wiki/VTK_FAQ
>> >
>> > Search the list archives at: http://markmail.org/search/?q=vtkusers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtkusers
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Search the list archives at: http://markmail.org/search/?q=
>> vtk-developers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>> >
>> >
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160919/2e555d47/attachment.html>

From f.perez475 at gmail.com  Tue Sep 20 07:21:18 2016
From: f.perez475 at gmail.com (Francisco Perez Salgado)
Date: Tue, 20 Sep 2016 13:21:18 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
Message-ID: <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>

Hi,

I wanted to know if there will be available debian packages (both runtime
and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to
install VTK through apt repositories instead from source code. I think it
would be so useful for final users.

Also, does VTK7 work with python 3.5 or it need python 2.7 yet?

Thanks in advance and best regards.
Fran.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/66be2884/attachment.html>

From mathieu.malaterre at gmail.com  Tue Sep 20 08:13:55 2016
From: mathieu.malaterre at gmail.com (Mathieu Malaterre)
Date: Tue, 20 Sep 2016 14:13:55 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
 <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
Message-ID: <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>

On Tue, Sep 20, 2016 at 1:21 PM, Francisco Perez Salgado
<f.perez475 at gmail.com> wrote:
> Hi,
>
> I wanted to know if there will be available debian packages (both runtime
> and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to install
> VTK through apt repositories instead from source code. I think it would be
> so useful for final users.

See:

https://bugs.debian.org/810254

2cts

From dave.demarle at kitware.com  Tue Sep 20 08:45:52 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 20 Sep 2016 08:45:52 -0400
Subject: [vtk-developers] [vtkusers]  poll - vtk doxygen style
In-Reply-To: <57E03C30.5010803@bluequartz.net>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
Message-ID: <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>

I count 9 votes for /** to 5 (including my own) for /// and none for /*! or
//!.

I'll go with this then:
/**
     something
     blah blah blah
*/

I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932 and on
Thursday.

Note

David Gobbi has another big style change coming that is going to
modernizing our indentation style in implementation files.
See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
That will go in very soon too.


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> +1 for >
> >     /**
> >       * Document code
> >       * @param
> >       */
>
> and leave them in the header file
>
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jackson at bluequartz.net
>
>
> David Lonie wrote:
>
>> One more vote for /** ... */ with leading * on lines in-between, and
>> keeping the docs in the headers. Jumping to a header is much faster and
>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>> anyone would want to volunteer for the task of moving all the
>> docstrings, and it doesn't sound easy to script/automate.
>>
>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>> <mailto:dan.lipsa at kitware.com>> wrote:
>>
>>     I also prefer this doxygen style:
>>
>>     /**
>>       * Document code
>>       * @param
>>       */
>>
>>     as it creates a nice header for a function that contains the
>>     documentation.
>>
>>     I think documentation should stay in the header as it is part of the
>>     interface of the module.
>>
>>
>>
>>
>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>> wrote:
>>
>>         The Doxygen isn't always there, when I am hunting issues I often
>> end
>>         up in the header for the class thanks to my IDE, and having the
>>         Doxygen there is often helpful whether the Doxygen is somewhere
>>         on the
>>         machine or not. I really dislike projects that put it in the
>>         implementation, and disagree on the method names being enough. I
>>         hope
>>         we leave it in the headers, and for the purposes of the migration
>> to
>>         real Doxygen I am not sure the tools have the necessary logic to
>>         move
>>         documentation - just transform the style.
>>
>>         I prefer the
>>
>>         /**
>>           * Document code
>>           * @param
>>           */
>>
>>         Style personally, but /// also works, never really liked the //!
>>         but I
>>         am sure I could adapt were that chosen.
>>
>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>> wrote:
>>          > Another argument for keeping all documentation in the header
>>         files is so
>>          > it's available in an install-tree-only situation. Some people
>>         use VTK
>>          > without the source tree around, and having the docs built
>>         into the header
>>          > files is quite nice in that scenario. If it were in the cxx
>>         files, it
>>          > wouldn't be available to such users.
>>          >
>>          >
>>          > David
>>          >
>>          >
>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>         <david.thompson at kitware.com <mailto:david.thompson at kitware.com>>
>>          > wrote:
>>          >
>>          > Hi Andrew,
>>          >
>>          > ...
>>          >
>>          > For what it is worth, I also believe that documentation
>>         should be with the
>>          > declaration simply because the header files are the ones
>>         people tend to
>>          > first look at not the definition. This is what VTK currently
>>         does. ...
>>          >
>>          >
>>          > I think that moving method (not class) documentation out of
>>         the headers
>>          > makes the headers much more terse and legible. For the vast
>>         majority of
>>          > classes, the method names themselves are enough
>>         documentation. In cases
>>          > where method names are not enough, it is nice to have the
>>         implementation
>>          > nearby. Methods with inline or macro-generated
>>         implementations would still
>>          > have documentation in the header, as would enums.
>>          >
>>          >     David
>>          >
>>          > _______________________________________________
>>          > Powered by www.kitware.com <http://www.kitware.com>
>>          >
>>          > Visit other Kitware open-source projects at
>>          > http://www.kitware.com/opensource/opensource.html
>>         <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 <http://www.vtk.org/Wiki/VTK_F
>> AQ>
>>          >
>>          > Search the list archives at:
>>         http://markmail.org/search/?q=vtkusers
>>         <http://markmail.org/search/?q=vtkusers>
>>          >
>>          > Follow this link to subscribe/unsubscribe:
>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>          >
>>          >
>>          > _______________________________________________
>>          > Powered by www.kitware.com <http://www.kitware.com>
>>          >
>>          > Visit other Kitware open-source projects at
>>          > http://www.kitware.com/opensource/opensource.html
>>         <http://www.kitware.com/opensource/opensource.html>
>>          >
>>          > Search the list archives at:
>>         http://markmail.org/search/?q=vtk-developers
>>         <http://markmail.org/search/?q=vtk-developers>
>>         >
>>         >  Follow this link to subscribe/unsubscribe:
>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>         >
>>         >
>>         _______________________________________________
>>         Powered by www.kitware.com <http://www.kitware.com>
>>
>>         Visit other Kitware open-source projects at
>>         http://www.kitware.com/opensource/opensource.html
>>         <http://www.kitware.com/opensource/opensource.html>
>>
>>         Search the list archives at:
>>         http://markmail.org/search/?q=vtk-developers
>>         <http://markmail.org/search/?q=vtk-developers>
>>
>>         Follow this link to subscribe/unsubscribe:
>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>
>>
>>
>>     _______________________________________________
>>     Powered by www.kitware.com <http://www.kitware.com>
>>
>>     Visit other Kitware open-source projects at
>>     http://www.kitware.com/opensource/opensource.html
>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ>
>>
>>     Search the list archives at: http://markmail.org/search/?q=vtkusers
>>     <http://markmail.org/search/?q=vtkusers>
>>
>>     Follow this link to subscribe/unsubscribe:
>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/50be832a/attachment-0001.html>

From f.perez475 at gmail.com  Tue Sep 20 08:52:11 2016
From: f.perez475 at gmail.com (Francisco Perez Salgado)
Date: Tue, 20 Sep 2016 14:52:11 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
 <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
 <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>
Message-ID: <CADSxNm0nJaCsXhOPdTC=YbRNhzJPbehCoD5zFt2G+QOjHDJNKg@mail.gmail.com>

Yep I saw that, but my question is: can I install the package via APT? In
that case, which repo should I install on my system? Ubuntu 16.04 APT repos
only have vtk5 and vtk6 by default. My idea is to install vtk with a simple
command like:

    apt-get install vtk7 vtk7-dev

or something similar. In the worst case scenario, can I generate a .deb
package by my own using CPack and upload it to my APT repo?

Thanks for the quick response.
Fran.

2016-09-20 14:13 GMT+02:00 Mathieu Malaterre <mathieu.malaterre at gmail.com>:

> On Tue, Sep 20, 2016 at 1:21 PM, Francisco Perez Salgado
> <f.perez475 at gmail.com> wrote:
> > Hi,
> >
> > I wanted to know if there will be available debian packages (both runtime
> > and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to
> install
> > VTK through apt repositories instead from source code. I think it would
> be
> > so useful for final users.
>
> See:
>
> https://bugs.debian.org/810254
>
> 2cts
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/c98fd6b5/attachment.html>

From dave.demarle at kitware.com  Tue Sep 20 08:54:14 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 20 Sep 2016 08:54:14 -0400
Subject: [vtk-developers] [Non-DoD Source] ready to branch for 7.1?
	(UNCLASSIFIED)
In-Reply-To: <10A03274360DCF47A6EE78C9952A31CA87D8B12B@UMECHPA7C.easf.csd.disa.mil>
References: <10A03274360DCF47A6EE78C9952A31CA87D8B12B@UMECHPA7C.easf.csd.disa.mil>
Message-ID: <CANjZAi-xuu6xhQkcr6um4OOE8PnY9ezUwez6NELtYkia1+-dhw@mail.gmail.com>

No spare time to review it yet.

my apologies

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Fri, Sep 16, 2016 at 4:39 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL
(US) <joseph.g.hennessey2.ctr at mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> David,
>
> Have you accepted my Xdmf merge request?
>
> Merge Request !1886
>
> I would like that to be in there, it has the latest changes to the Xdmf
> library,
>
> As well as my updated reader/writer for VTK and a new parallel writer for
> VTK.
>
> Thanks,
>
> Joe
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Joseph G. Hennessey Ph.D., Leidos
> Army Research Lab
> DOD Supercomputing Resource Center
> Aberdeen Proving Ground, MD 21005
> Email:  joseph.g.hennessey2.ctr at mail.mil
>
>
> -----Original Message-----
> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
> David E DeMarle
> Sent: Friday, September 16, 2016 2:46 PM
> To: vtkdev <vtk-developers at vtk.org>
> Cc: Elvis Stansvik <elvis.stansvik at orexplore.com>
> Subject: [Non-DoD Source] [vtk-developers] ready to branch for 7.1?
>
> Does anyone out that have partially completed work in progress that we
> should
> delay the release branch point for?
>
> We are hoping to get 7.1 started in a day or two.
>
> thanks,
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> CLASSIFICATION: UNCLASSIFIED
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/363e1fa7/attachment.html>

From elvis.stansvik at orexplore.com  Tue Sep 20 10:23:04 2016
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 20 Sep 2016 16:23:04 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <CADSxNm0nJaCsXhOPdTC=YbRNhzJPbehCoD5zFt2G+QOjHDJNKg@mail.gmail.com>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
 <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
 <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>
 <CADSxNm0nJaCsXhOPdTC=YbRNhzJPbehCoD5zFt2G+QOjHDJNKg@mail.gmail.com>
Message-ID: <CAE-7VJnA09eb=FZEZD2xtp2qZ+y0WHTnK1z0fDS0vjmBZ8epww@mail.gmail.com>

2016-09-20 14:52 GMT+02:00 Francisco Perez Salgado <f.perez475 at gmail.com>:
> Yep I saw that, but my question is: can I install the package via APT? In
> that case, which repo should I install on my system? Ubuntu 16.04 APT repos
> only have vtk5 and vtk6 by default. My idea is to install vtk with a simple
> command like:
>
>     apt-get install vtk7 vtk7-dev
>
> or something similar. In the worst case scenario, can I generate a .deb
> package by my own using CPack and upload it to my APT repo?

Hi Francisco,

As you can see in the bug report linked by Mathieu, Ghislain (package
maintainer) has withdrawn his intention to package VTK 7 :( I didn't
know this (I was in contact with Ghislain a few months ago, asking
what the progress was).

As we needed packages of VTK 7 for work (where we use Kubuntu 16.04).
I made a single VTK 7 package and uploaded it to this PPA:

    https://launchpad.net/~elvstone/+archive/ubuntu/vtk7

You can add the repository and install the package with:

    sudo add-apt-repository ppa:elvstone/vtk7
    sudo apt-get update
    sudo apt-get install vtk7

But note that:

    1) This VTK build might not be configured exactly like you want
(see the PPA for what CMake options I used).
    2) I'm not updating the PPA anymore as we've switched to using an
internal APT repo, feel free take my package and make your own.
    3) The package does not follow Debian packaging policies, e.g:
        - It installs everything to /opt/VTK-7.0.0 (to not conflict
with VTK 6 packages from main repos)
        - It's one single package (no split -dev packages)

Regarding Python, this package has Python 3 bindings (though since I
made the package, we've switched to C++ here at work).

Hope this PPA can be of use until someone steps up to do a proper
Debian packaging of VTK 7.

Cheers,
Elvis

>
> Thanks for the quick response.
> Fran.
>
> 2016-09-20 14:13 GMT+02:00 Mathieu Malaterre <mathieu.malaterre at gmail.com>:
>>
>> On Tue, Sep 20, 2016 at 1:21 PM, Francisco Perez Salgado
>> <f.perez475 at gmail.com> wrote:
>> > Hi,
>> >
>> > I wanted to know if there will be available debian packages (both
>> > runtime
>> > and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to
>> > install
>> > VTK through apt repositories instead from source code. I think it would
>> > be
>> > so useful for final users.
>>
>> See:
>>
>> https://bugs.debian.org/810254
>>
>> 2cts
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>

From f.perez475 at gmail.com  Tue Sep 20 10:29:38 2016
From: f.perez475 at gmail.com (Francisco Perez Salgado)
Date: Tue, 20 Sep 2016 16:29:38 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <CAE-7VJnA09eb=FZEZD2xtp2qZ+y0WHTnK1z0fDS0vjmBZ8epww@mail.gmail.com>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
 <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
 <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>
 <CADSxNm0nJaCsXhOPdTC=YbRNhzJPbehCoD5zFt2G+QOjHDJNKg@mail.gmail.com>
 <CAE-7VJnA09eb=FZEZD2xtp2qZ+y0WHTnK1z0fDS0vjmBZ8epww@mail.gmail.com>
Message-ID: <CADSxNm3xFzrwULfpVYbS35Q2k4-=+GyKHm91hMnNZ4q6BJHejA@mail.gmail.com>

Hi Elvis,

thank you very much for the info. Yes I saw your package searching in
Google; actually I'm using that one but I just wanted to know if it would
be official support from vtk.
Again thank you very much, your package is very useful.

Regards,
Fran.
El 20/09/2016 16:23, "Elvis Stansvik" <elvis.stansvik at orexplore.com>
escribi?:

> 2016-09-20 14:52 GMT+02:00 Francisco Perez Salgado <f.perez475 at gmail.com>:
> > Yep I saw that, but my question is: can I install the package via APT? In
> > that case, which repo should I install on my system? Ubuntu 16.04 APT
> repos
> > only have vtk5 and vtk6 by default. My idea is to install vtk with a
> simple
> > command like:
> >
> >     apt-get install vtk7 vtk7-dev
> >
> > or something similar. In the worst case scenario, can I generate a .deb
> > package by my own using CPack and upload it to my APT repo?
>
> Hi Francisco,
>
> As you can see in the bug report linked by Mathieu, Ghislain (package
> maintainer) has withdrawn his intention to package VTK 7 :( I didn't
> know this (I was in contact with Ghislain a few months ago, asking
> what the progress was).
>
> As we needed packages of VTK 7 for work (where we use Kubuntu 16.04).
> I made a single VTK 7 package and uploaded it to this PPA:
>
>     https://launchpad.net/~elvstone/+archive/ubuntu/vtk7
>
> You can add the repository and install the package with:
>
>     sudo add-apt-repository ppa:elvstone/vtk7
>     sudo apt-get update
>     sudo apt-get install vtk7
>
> But note that:
>
>     1) This VTK build might not be configured exactly like you want
> (see the PPA for what CMake options I used).
>     2) I'm not updating the PPA anymore as we've switched to using an
> internal APT repo, feel free take my package and make your own.
>     3) The package does not follow Debian packaging policies, e.g:
>         - It installs everything to /opt/VTK-7.0.0 (to not conflict
> with VTK 6 packages from main repos)
>         - It's one single package (no split -dev packages)
>
> Regarding Python, this package has Python 3 bindings (though since I
> made the package, we've switched to C++ here at work).
>
> Hope this PPA can be of use until someone steps up to do a proper
> Debian packaging of VTK 7.
>
> Cheers,
> Elvis
>
> >
> > Thanks for the quick response.
> > Fran.
> >
> > 2016-09-20 14:13 GMT+02:00 Mathieu Malaterre <
> mathieu.malaterre at gmail.com>:
> >>
> >> On Tue, Sep 20, 2016 at 1:21 PM, Francisco Perez Salgado
> >> <f.perez475 at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > I wanted to know if there will be available debian packages (both
> >> > runtime
> >> > and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to
> >> > install
> >> > VTK through apt repositories instead from source code. I think it
> would
> >> > be
> >> > so useful for final users.
> >>
> >> See:
> >>
> >> https://bugs.debian.org/810254
> >>
> >> 2cts
> >
> >
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=
> vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtk-developers
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/aabc9e2b/attachment-0001.html>

From elvis.stansvik at orexplore.com  Tue Sep 20 10:41:55 2016
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 20 Sep 2016 16:41:55 +0200
Subject: [vtk-developers] Fwd: VTK7 debian packages for Ubuntu 16.04
In-Reply-To: <CADSxNm3xFzrwULfpVYbS35Q2k4-=+GyKHm91hMnNZ4q6BJHejA@mail.gmail.com>
References: <mailman.4994.1474370419.17623.vtk-developers@vtk.org>
 <CADSxNm0v4EHEwsKeB8Xqiz7wbqnCTJnBk7bnt45Z2bFeEq1mAg@mail.gmail.com>
 <CA+7wUsyoq1ym-cgpppQPhz3hhq2k0=5tobRYPtu-yPvkjASzzw@mail.gmail.com>
 <CADSxNm0nJaCsXhOPdTC=YbRNhzJPbehCoD5zFt2G+QOjHDJNKg@mail.gmail.com>
 <CAE-7VJnA09eb=FZEZD2xtp2qZ+y0WHTnK1z0fDS0vjmBZ8epww@mail.gmail.com>
 <CADSxNm3xFzrwULfpVYbS35Q2k4-=+GyKHm91hMnNZ4q6BJHejA@mail.gmail.com>
Message-ID: <CAE-7VJkK+MKTdgMLywNMgVnSUZkDFmT4ibHnFf9Jazvt9D4DBA@mail.gmail.com>

2016-09-20 16:29 GMT+02:00 Francisco Perez Salgado <f.perez475 at gmail.com>:
> Hi Elvis,
>
> thank you very much for the info. Yes I saw your package searching in
> Google; actually I'm using that one but I just wanted to know if it would be
> official support from vtk.

Ah. I don't think Kitware ever produced Ubuntu packages of VTK of
that's what you mean.

What's needed now is Debian packagers willing to take on the work of
making a package.

It's quite a bit more work to create a package that follows all the
Debian packaging standards (so that it can be accepted into official
repositories). With the package I did I took a lot of shortcuts so to
speak.

> Again thank you very much, your package is very useful.

Glad it could help some.

Elvis

>
> Regards,
> Fran.
>
> El 20/09/2016 16:23, "Elvis Stansvik" <elvis.stansvik at orexplore.com>
> escribi?:
>>
>> 2016-09-20 14:52 GMT+02:00 Francisco Perez Salgado <f.perez475 at gmail.com>:
>> > Yep I saw that, but my question is: can I install the package via APT?
>> > In
>> > that case, which repo should I install on my system? Ubuntu 16.04 APT
>> > repos
>> > only have vtk5 and vtk6 by default. My idea is to install vtk with a
>> > simple
>> > command like:
>> >
>> >     apt-get install vtk7 vtk7-dev
>> >
>> > or something similar. In the worst case scenario, can I generate a .deb
>> > package by my own using CPack and upload it to my APT repo?
>>
>> Hi Francisco,
>>
>> As you can see in the bug report linked by Mathieu, Ghislain (package
>> maintainer) has withdrawn his intention to package VTK 7 :( I didn't
>> know this (I was in contact with Ghislain a few months ago, asking
>> what the progress was).
>>
>> As we needed packages of VTK 7 for work (where we use Kubuntu 16.04).
>> I made a single VTK 7 package and uploaded it to this PPA:
>>
>>     https://launchpad.net/~elvstone/+archive/ubuntu/vtk7
>>
>> You can add the repository and install the package with:
>>
>>     sudo add-apt-repository ppa:elvstone/vtk7
>>     sudo apt-get update
>>     sudo apt-get install vtk7
>>
>> But note that:
>>
>>     1) This VTK build might not be configured exactly like you want
>> (see the PPA for what CMake options I used).
>>     2) I'm not updating the PPA anymore as we've switched to using an
>> internal APT repo, feel free take my package and make your own.
>>     3) The package does not follow Debian packaging policies, e.g:
>>         - It installs everything to /opt/VTK-7.0.0 (to not conflict
>> with VTK 6 packages from main repos)
>>         - It's one single package (no split -dev packages)
>>
>> Regarding Python, this package has Python 3 bindings (though since I
>> made the package, we've switched to C++ here at work).
>>
>> Hope this PPA can be of use until someone steps up to do a proper
>> Debian packaging of VTK 7.
>>
>> Cheers,
>> Elvis
>>
>> >
>> > Thanks for the quick response.
>> > Fran.
>> >
>> > 2016-09-20 14:13 GMT+02:00 Mathieu Malaterre
>> > <mathieu.malaterre at gmail.com>:
>> >>
>> >> On Tue, Sep 20, 2016 at 1:21 PM, Francisco Perez Salgado
>> >> <f.perez475 at gmail.com> wrote:
>> >> > Hi,
>> >> >
>> >> > I wanted to know if there will be available debian packages (both
>> >> > runtime
>> >> > and develop packages) for Ubuntu 16.04 (Xenial) soon. The goal is to
>> >> > install
>> >> > VTK through apt repositories instead from source code. I think it
>> >> > would
>> >> > be
>> >> > so useful for final users.
>> >>
>> >> See:
>> >>
>> >> https://bugs.debian.org/810254
>> >>
>> >> 2cts
>> >
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Search the list archives at:
>> > http://markmail.org/search/?q=vtk-developers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>> >
>> >

From dave.demarle at kitware.com  Tue Sep 20 14:20:44 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 20 Sep 2016 14:20:44 -0400
Subject: [vtk-developers] [vtkusers]  poll - vtk doxygen style
In-Reply-To: <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
Message-ID: <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>

https://gitlab.kitware.com/vtk/vtk/merge_requests/1932

Pending test failures I'll merge Wednesday or Thursday evening.


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> I count 9 votes for /** to 5 (including my own) for /// and none for /*!
> or //!.
>
> I'll go with this then:
> /**
>      something
>      blah blah blah
> */
>
> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932 and on
> Thursday.
>
> Note
>
> David Gobbi has another big style change coming that is going to
> modernizing our indentation style in implementation files.
> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
> That will go in very soon too.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
>
>> +1 for >
>> >     /**
>> >       * Document code
>> >       * @param
>> >       */
>>
>> and leave them in the header file
>>
>> --
>> Michael A. Jackson
>> BlueQuartz Software, LLC
>> [e]: mike.jackson at bluequartz.net
>>
>>
>> David Lonie wrote:
>>
>>> One more vote for /** ... */ with leading * on lines in-between, and
>>> keeping the docs in the headers. Jumping to a header is much faster and
>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>> anyone would want to volunteer for the task of moving all the
>>> docstrings, and it doesn't sound easy to script/automate.
>>>
>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>
>>>     I also prefer this doxygen style:
>>>
>>>     /**
>>>       * Document code
>>>       * @param
>>>       */
>>>
>>>     as it creates a nice header for a function that contains the
>>>     documentation.
>>>
>>>     I think documentation should stay in the header as it is part of the
>>>     interface of the module.
>>>
>>>
>>>
>>>
>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>> wrote:
>>>
>>>         The Doxygen isn't always there, when I am hunting issues I often
>>> end
>>>         up in the header for the class thanks to my IDE, and having the
>>>         Doxygen there is often helpful whether the Doxygen is somewhere
>>>         on the
>>>         machine or not. I really dislike projects that put it in the
>>>         implementation, and disagree on the method names being enough. I
>>>         hope
>>>         we leave it in the headers, and for the purposes of the
>>> migration to
>>>         real Doxygen I am not sure the tools have the necessary logic to
>>>         move
>>>         documentation - just transform the style.
>>>
>>>         I prefer the
>>>
>>>         /**
>>>           * Document code
>>>           * @param
>>>           */
>>>
>>>         Style personally, but /// also works, never really liked the //!
>>>         but I
>>>         am sure I could adapt were that chosen.
>>>
>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>> wrote:
>>>          > Another argument for keeping all documentation in the header
>>>         files is so
>>>          > it's available in an install-tree-only situation. Some people
>>>         use VTK
>>>          > without the source tree around, and having the docs built
>>>         into the header
>>>          > files is quite nice in that scenario. If it were in the cxx
>>>         files, it
>>>          > wouldn't be available to such users.
>>>          >
>>>          >
>>>          > David
>>>          >
>>>          >
>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware.com>>
>>>          > wrote:
>>>          >
>>>          > Hi Andrew,
>>>          >
>>>          > ...
>>>          >
>>>          > For what it is worth, I also believe that documentation
>>>         should be with the
>>>          > declaration simply because the header files are the ones
>>>         people tend to
>>>          > first look at not the definition. This is what VTK currently
>>>         does. ...
>>>          >
>>>          >
>>>          > I think that moving method (not class) documentation out of
>>>         the headers
>>>          > makes the headers much more terse and legible. For the vast
>>>         majority of
>>>          > classes, the method names themselves are enough
>>>         documentation. In cases
>>>          > where method names are not enough, it is nice to have the
>>>         implementation
>>>          > nearby. Methods with inline or macro-generated
>>>         implementations would still
>>>          > have documentation in the header, as would enums.
>>>          >
>>>          >     David
>>>          >
>>>          > _______________________________________________
>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>          >
>>>          > Visit other Kitware open-source projects at
>>>          > http://www.kitware.com/opensource/opensource.html
>>>         <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 <
>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>          >
>>>          > Search the list archives at:
>>>         http://markmail.org/search/?q=vtkusers
>>>         <http://markmail.org/search/?q=vtkusers>
>>>          >
>>>          > Follow this link to subscribe/unsubscribe:
>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>          >
>>>          >
>>>          > _______________________________________________
>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>          >
>>>          > Visit other Kitware open-source projects at
>>>          > http://www.kitware.com/opensource/opensource.html
>>>         <http://www.kitware.com/opensource/opensource.html>
>>>          >
>>>          > Search the list archives at:
>>>         http://markmail.org/search/?q=vtk-developers
>>>         <http://markmail.org/search/?q=vtk-developers>
>>>         >
>>>         >  Follow this link to subscribe/unsubscribe:
>>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>         >
>>>         >
>>>         _______________________________________________
>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>
>>>         Visit other Kitware open-source projects at
>>>         http://www.kitware.com/opensource/opensource.html
>>>         <http://www.kitware.com/opensource/opensource.html>
>>>
>>>         Search the list archives at:
>>>         http://markmail.org/search/?q=vtk-developers
>>>         <http://markmail.org/search/?q=vtk-developers>
>>>
>>>         Follow this link to subscribe/unsubscribe:
>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>
>>>     Visit other Kitware open-source projects at
>>>     http://www.kitware.com/opensource/opensource.html
>>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ>
>>>
>>>     Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>     <http://markmail.org/search/?q=vtkusers>
>>>
>>>     Follow this link to subscribe/unsubscribe:
>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/8bb668f3/attachment-0001.html>

From berk.geveci at kitware.com  Tue Sep 20 15:10:17 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Tue, 20 Sep 2016 15:10:17 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
Message-ID: <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>

That seems to generate a lot of unnecessary group ( //@{ ) markings. Isn't
there a way of avoiding that? Also, I thought that this was going to be
merged together with the indentation changes to avoid multiple conflicts?

On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>
> Pending test failures I'll merge Wednesday or Thursday evening.
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> I count 9 votes for /** to 5 (including my own) for /// and none for /*!
>> or //!.
>>
>> I'll go with this then:
>> /**
>>      something
>>      blah blah blah
>> */
>>
>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932 and
>> on Thursday.
>>
>> Note
>>
>> David Gobbi has another big style change coming that is going to
>> modernizing our indentation style in implementation files.
>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>> That will go in very soon too.
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>> mike.jackson at bluequartz.net> wrote:
>>
>>> +1 for >
>>> >     /**
>>> >       * Document code
>>> >       * @param
>>> >       */
>>>
>>> and leave them in the header file
>>>
>>> --
>>> Michael A. Jackson
>>> BlueQuartz Software, LLC
>>> [e]: mike.jackson at bluequartz.net
>>>
>>>
>>> David Lonie wrote:
>>>
>>>> One more vote for /** ... */ with leading * on lines in-between, and
>>>> keeping the docs in the headers. Jumping to a header is much faster and
>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>> anyone would want to volunteer for the task of moving all the
>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>
>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>
>>>>     I also prefer this doxygen style:
>>>>
>>>>     /**
>>>>       * Document code
>>>>       * @param
>>>>       */
>>>>
>>>>     as it creates a nice header for a function that contains the
>>>>     documentation.
>>>>
>>>>     I think documentation should stay in the header as it is part of the
>>>>     interface of the module.
>>>>
>>>>
>>>>
>>>>
>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>> wrote:
>>>>
>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>> often end
>>>>         up in the header for the class thanks to my IDE, and having the
>>>>         Doxygen there is often helpful whether the Doxygen is somewhere
>>>>         on the
>>>>         machine or not. I really dislike projects that put it in the
>>>>         implementation, and disagree on the method names being enough. I
>>>>         hope
>>>>         we leave it in the headers, and for the purposes of the
>>>> migration to
>>>>         real Doxygen I am not sure the tools have the necessary logic to
>>>>         move
>>>>         documentation - just transform the style.
>>>>
>>>>         I prefer the
>>>>
>>>>         /**
>>>>           * Document code
>>>>           * @param
>>>>           */
>>>>
>>>>         Style personally, but /// also works, never really liked the //!
>>>>         but I
>>>>         am sure I could adapt were that chosen.
>>>>
>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>> wrote:
>>>>          > Another argument for keeping all documentation in the header
>>>>         files is so
>>>>          > it's available in an install-tree-only situation. Some people
>>>>         use VTK
>>>>          > without the source tree around, and having the docs built
>>>>         into the header
>>>>          > files is quite nice in that scenario. If it were in the cxx
>>>>         files, it
>>>>          > wouldn't be available to such users.
>>>>          >
>>>>          >
>>>>          > David
>>>>          >
>>>>          >
>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware.com
>>>> >>
>>>>          > wrote:
>>>>          >
>>>>          > Hi Andrew,
>>>>          >
>>>>          > ...
>>>>          >
>>>>          > For what it is worth, I also believe that documentation
>>>>         should be with the
>>>>          > declaration simply because the header files are the ones
>>>>         people tend to
>>>>          > first look at not the definition. This is what VTK currently
>>>>         does. ...
>>>>          >
>>>>          >
>>>>          > I think that moving method (not class) documentation out of
>>>>         the headers
>>>>          > makes the headers much more terse and legible. For the vast
>>>>         majority of
>>>>          > classes, the method names themselves are enough
>>>>         documentation. In cases
>>>>          > where method names are not enough, it is nice to have the
>>>>         implementation
>>>>          > nearby. Methods with inline or macro-generated
>>>>         implementations would still
>>>>          > have documentation in the header, as would enums.
>>>>          >
>>>>          >     David
>>>>          >
>>>>          > _______________________________________________
>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>          >
>>>>          > Visit other Kitware open-source projects at
>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>         <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 <
>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>          >
>>>>          > Search the list archives at:
>>>>         http://markmail.org/search/?q=vtkusers
>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>          >
>>>>          > Follow this link to subscribe/unsubscribe:
>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>          >
>>>>          >
>>>>          > _______________________________________________
>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>          >
>>>>          > Visit other Kitware open-source projects at
>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>          >
>>>>          > Search the list archives at:
>>>>         http://markmail.org/search/?q=vtk-developers
>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>         >
>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>         >
>>>>         >
>>>>         _______________________________________________
>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>
>>>>         Visit other Kitware open-source projects at
>>>>         http://www.kitware.com/opensource/opensource.html
>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>
>>>>         Search the list archives at:
>>>>         http://markmail.org/search/?q=vtk-developers
>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>
>>>>         Follow this link to subscribe/unsubscribe:
>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>
>>>>     Visit other Kitware open-source projects at
>>>>     http://www.kitware.com/opensource/opensource.html
>>>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ>
>>>>
>>>>     Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>
>>>>     Follow this link to subscribe/unsubscribe:
>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>
>>
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/ecf3268a/attachment-0001.html>

From dave.demarle at kitware.com  Tue Sep 20 15:27:45 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 20 Sep 2016 15:27:45 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
Message-ID: <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>

Had been planing on this one day and then the indents the next, but sure we
can merge this into that branch first or the other way around.

Then we'll all just have a single merge commit to jump over rather than two.

I can take a stab at the groups with a better condition here: 547
<https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>

<https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> That seems to generate a lot of unnecessary group ( //@{ ) markings. Isn't
> there a way of avoiding that? Also, I thought that this was going to be
> merged together with the indentation changes to avoid multiple conflicts?
>
> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>
>> Pending test failures I'll merge Wednesday or Thursday evening.
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>> dave.demarle at kitware.com> wrote:
>>
>>> I count 9 votes for /** to 5 (including my own) for /// and none for /*!
>>> or //!.
>>>
>>> I'll go with this then:
>>> /**
>>>      something
>>>      blah blah blah
>>> */
>>>
>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932 and
>>> on Thursday.
>>>
>>> Note
>>>
>>> David Gobbi has another big style change coming that is going to
>>> modernizing our indentation style in implementation files.
>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>> That will go in very soon too.
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>> mike.jackson at bluequartz.net> wrote:
>>>
>>>> +1 for >
>>>> >     /**
>>>> >       * Document code
>>>> >       * @param
>>>> >       */
>>>>
>>>> and leave them in the header file
>>>>
>>>> --
>>>> Michael A. Jackson
>>>> BlueQuartz Software, LLC
>>>> [e]: mike.jackson at bluequartz.net
>>>>
>>>>
>>>> David Lonie wrote:
>>>>
>>>>> One more vote for /** ... */ with leading * on lines in-between, and
>>>>> keeping the docs in the headers. Jumping to a header is much faster and
>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>> anyone would want to volunteer for the task of moving all the
>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>
>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>
>>>>>     I also prefer this doxygen style:
>>>>>
>>>>>     /**
>>>>>       * Document code
>>>>>       * @param
>>>>>       */
>>>>>
>>>>>     as it creates a nice header for a function that contains the
>>>>>     documentation.
>>>>>
>>>>>     I think documentation should stay in the header as it is part of
>>>>> the
>>>>>     interface of the module.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>>> wrote:
>>>>>
>>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>>> often end
>>>>>         up in the header for the class thanks to my IDE, and having the
>>>>>         Doxygen there is often helpful whether the Doxygen is somewhere
>>>>>         on the
>>>>>         machine or not. I really dislike projects that put it in the
>>>>>         implementation, and disagree on the method names being enough.
>>>>> I
>>>>>         hope
>>>>>         we leave it in the headers, and for the purposes of the
>>>>> migration to
>>>>>         real Doxygen I am not sure the tools have the necessary logic
>>>>> to
>>>>>         move
>>>>>         documentation - just transform the style.
>>>>>
>>>>>         I prefer the
>>>>>
>>>>>         /**
>>>>>           * Document code
>>>>>           * @param
>>>>>           */
>>>>>
>>>>>         Style personally, but /// also works, never really liked the
>>>>> //!
>>>>>         but I
>>>>>         am sure I could adapt were that chosen.
>>>>>
>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via vtk-developers
>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>> wrote:
>>>>>          > Another argument for keeping all documentation in the header
>>>>>         files is so
>>>>>          > it's available in an install-tree-only situation. Some
>>>>> people
>>>>>         use VTK
>>>>>          > without the source tree around, and having the docs built
>>>>>         into the header
>>>>>          > files is quite nice in that scenario. If it were in the cxx
>>>>>         files, it
>>>>>          > wouldn't be available to such users.
>>>>>          >
>>>>>          >
>>>>>          > David
>>>>>          >
>>>>>          >
>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware.com
>>>>> >>
>>>>>          > wrote:
>>>>>          >
>>>>>          > Hi Andrew,
>>>>>          >
>>>>>          > ...
>>>>>          >
>>>>>          > For what it is worth, I also believe that documentation
>>>>>         should be with the
>>>>>          > declaration simply because the header files are the ones
>>>>>         people tend to
>>>>>          > first look at not the definition. This is what VTK currently
>>>>>         does. ...
>>>>>          >
>>>>>          >
>>>>>          > I think that moving method (not class) documentation out of
>>>>>         the headers
>>>>>          > makes the headers much more terse and legible. For the vast
>>>>>         majority of
>>>>>          > classes, the method names themselves are enough
>>>>>         documentation. In cases
>>>>>          > where method names are not enough, it is nice to have the
>>>>>         implementation
>>>>>          > nearby. Methods with inline or macro-generated
>>>>>         implementations would still
>>>>>          > have documentation in the header, as would enums.
>>>>>          >
>>>>>          >     David
>>>>>          >
>>>>>          > _______________________________________________
>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>          >
>>>>>          > Visit other Kitware open-source projects at
>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>         <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 <
>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>          >
>>>>>          > Search the list archives at:
>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>          >
>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>          >
>>>>>          >
>>>>>          > _______________________________________________
>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>          >
>>>>>          > Visit other Kitware open-source projects at
>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>          >
>>>>>          > Search the list archives at:
>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>         >
>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>         >
>>>>>         >
>>>>>         _______________________________________________
>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>
>>>>>         Visit other Kitware open-source projects at
>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>
>>>>>         Search the list archives at:
>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>
>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>
>>>>>     Visit other Kitware open-source projects at
>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>
>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>> vtkusers
>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>
>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/b0eb63e1/attachment-0001.html>

From david.gobbi at gmail.com  Tue Sep 20 16:00:09 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 20 Sep 2016 14:00:09 -0600
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
 <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
Message-ID: <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>

Dave,

Probably the easiest thing is if you tell me when you're ready to merge the
doxygen change, and then I'll use that as a base for the brace change MR
(i.e. I'll re-run my script).  Then when the regenerated brace-change MR is
merged into VTK, the doxygen change will go with it.

We obviously cannot merge the brace-change MR into the doxyen MR or vice
versa... there would be thousands of conflicts.  These kind of changes have
to be serial.

 - David

On Tue, Sep 20, 2016 at 1:27 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Had been planing on this one day and then the indents the next, but sure
> we can merge this into that branch first or the other way around.
>
> Then we'll all just have a single merge commit to jump over rather than
> two.
>
> I can take a stab at the groups with a better condition here: 547
> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>
>
> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> That seems to generate a lot of unnecessary group ( //@{ ) markings.
>> Isn't there a way of avoiding that? Also, I thought that this was going to
>> be merged together with the indentation changes to avoid multiple conflicts?
>>
>> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <
>> dave.demarle at kitware.com> wrote:
>>
>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>
>>> Pending test failures I'll merge Wednesday or Thursday evening.
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>>> dave.demarle at kitware.com> wrote:
>>>
>>>> I count 9 votes for /** to 5 (including my own) for /// and none for
>>>> /*! or //!.
>>>>
>>>> I'll go with this then:
>>>> /**
>>>>      something
>>>>      blah blah blah
>>>> */
>>>>
>>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932 and
>>>> on Thursday.
>>>>
>>>> Note
>>>>
>>>> David Gobbi has another big style change coming that is going to
>>>> modernizing our indentation style in implementation files.
>>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>>> That will go in very soon too.
>>>>
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909
>>>>
>>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>>> mike.jackson at bluequartz.net> wrote:
>>>>
>>>>> +1 for >
>>>>> >     /**
>>>>> >       * Document code
>>>>> >       * @param
>>>>> >       */
>>>>>
>>>>> and leave them in the header file
>>>>>
>>>>> --
>>>>> Michael A. Jackson
>>>>> BlueQuartz Software, LLC
>>>>> [e]: mike.jackson at bluequartz.net
>>>>>
>>>>>
>>>>> David Lonie wrote:
>>>>>
>>>>>> One more vote for /** ... */ with leading * on lines in-between, and
>>>>>> keeping the docs in the headers. Jumping to a header is much faster
>>>>>> and
>>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>>> anyone would want to volunteer for the task of moving all the
>>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>>
>>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>>
>>>>>>     I also prefer this doxygen style:
>>>>>>
>>>>>>     /**
>>>>>>       * Document code
>>>>>>       * @param
>>>>>>       */
>>>>>>
>>>>>>     as it creates a nice header for a function that contains the
>>>>>>     documentation.
>>>>>>
>>>>>>     I think documentation should stay in the header as it is part of
>>>>>> the
>>>>>>     interface of the module.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>>>> wrote:
>>>>>>
>>>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>>>> often end
>>>>>>         up in the header for the class thanks to my IDE, and having
>>>>>> the
>>>>>>         Doxygen there is often helpful whether the Doxygen is
>>>>>> somewhere
>>>>>>         on the
>>>>>>         machine or not. I really dislike projects that put it in the
>>>>>>         implementation, and disagree on the method names being
>>>>>> enough. I
>>>>>>         hope
>>>>>>         we leave it in the headers, and for the purposes of the
>>>>>> migration to
>>>>>>         real Doxygen I am not sure the tools have the necessary logic
>>>>>> to
>>>>>>         move
>>>>>>         documentation - just transform the style.
>>>>>>
>>>>>>         I prefer the
>>>>>>
>>>>>>         /**
>>>>>>           * Document code
>>>>>>           * @param
>>>>>>           */
>>>>>>
>>>>>>         Style personally, but /// also works, never really liked the
>>>>>> //!
>>>>>>         but I
>>>>>>         am sure I could adapt were that chosen.
>>>>>>
>>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via
>>>>>> vtk-developers
>>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>>> wrote:
>>>>>>          > Another argument for keeping all documentation in the
>>>>>> header
>>>>>>         files is so
>>>>>>          > it's available in an install-tree-only situation. Some
>>>>>> people
>>>>>>         use VTK
>>>>>>          > without the source tree around, and having the docs built
>>>>>>         into the header
>>>>>>          > files is quite nice in that scenario. If it were in the cxx
>>>>>>         files, it
>>>>>>          > wouldn't be available to such users.
>>>>>>          >
>>>>>>          >
>>>>>>          > David
>>>>>>          >
>>>>>>          >
>>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware
>>>>>> .com>>
>>>>>>          > wrote:
>>>>>>          >
>>>>>>          > Hi Andrew,
>>>>>>          >
>>>>>>          > ...
>>>>>>          >
>>>>>>          > For what it is worth, I also believe that documentation
>>>>>>         should be with the
>>>>>>          > declaration simply because the header files are the ones
>>>>>>         people tend to
>>>>>>          > first look at not the definition. This is what VTK
>>>>>> currently
>>>>>>         does. ...
>>>>>>          >
>>>>>>          >
>>>>>>          > I think that moving method (not class) documentation out of
>>>>>>         the headers
>>>>>>          > makes the headers much more terse and legible. For the vast
>>>>>>         majority of
>>>>>>          > classes, the method names themselves are enough
>>>>>>         documentation. In cases
>>>>>>          > where method names are not enough, it is nice to have the
>>>>>>         implementation
>>>>>>          > nearby. Methods with inline or macro-generated
>>>>>>         implementations would still
>>>>>>          > have documentation in the header, as would enums.
>>>>>>          >
>>>>>>          >     David
>>>>>>          >
>>>>>>          > _______________________________________________
>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>          >
>>>>>>          > Visit other Kitware open-source projects at
>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>         <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 <
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>          >
>>>>>>          > Search the list archives at:
>>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>>          >
>>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>          >
>>>>>>          >
>>>>>>          > _______________________________________________
>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>          >
>>>>>>          > Visit other Kitware open-source projects at
>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>          >
>>>>>>          > Search the list archives at:
>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>         >
>>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>         >
>>>>>>         >
>>>>>>         _______________________________________________
>>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>>
>>>>>>         Visit other Kitware open-source projects at
>>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>
>>>>>>         Search the list archives at:
>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>
>>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>>
>>>>>>     Visit other Kitware open-source projects at
>>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>
>>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>>> vtkusers
>>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>>
>>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>
>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at: http://markmail.org/search/?q=
>>> vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/5495b79b/attachment-0001.html>

From dave.demarle at kitware.com  Tue Sep 20 16:07:37 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 20 Sep 2016 16:07:37 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
 <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
 <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>
Message-ID: <CANjZAi_eX9ypd+PphW6h43LmdbC3A0BwJZi1kM9K4dtWu_Vwdg@mail.gmail.com>

Sounds like a plan.

I'll address Berk's and Dan's suggestions then hand off to you.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Sep 20, 2016 at 4:00 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Dave,
>
> Probably the easiest thing is if you tell me when you're ready to merge
> the doxygen change, and then I'll use that as a base for the brace change
> MR (i.e. I'll re-run my script).  Then when the regenerated brace-change MR
> is merged into VTK, the doxygen change will go with it.
>
> We obviously cannot merge the brace-change MR into the doxyen MR or vice
> versa... there would be thousands of conflicts.  These kind of changes have
> to be serial.
>
>  - David
>
> On Tue, Sep 20, 2016 at 1:27 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> Had been planing on this one day and then the indents the next, but sure
>> we can merge this into that branch first or the other way around.
>>
>> Then we'll all just have a single merge commit to jump over rather than
>> two.
>>
>> I can take a stab at the groups with a better condition here: 547
>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>
>>
>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> That seems to generate a lot of unnecessary group ( //@{ ) markings.
>>> Isn't there a way of avoiding that? Also, I thought that this was going to
>>> be merged together with the indentation changes to avoid multiple conflicts?
>>>
>>> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <
>>> dave.demarle at kitware.com> wrote:
>>>
>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>
>>>> Pending test failures I'll merge Wednesday or Thursday evening.
>>>>
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909
>>>>
>>>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>>>> dave.demarle at kitware.com> wrote:
>>>>
>>>>> I count 9 votes for /** to 5 (including my own) for /// and none for
>>>>> /*! or //!.
>>>>>
>>>>> I'll go with this then:
>>>>> /**
>>>>>      something
>>>>>      blah blah blah
>>>>> */
>>>>>
>>>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>> and on Thursday.
>>>>>
>>>>> Note
>>>>>
>>>>> David Gobbi has another big style change coming that is going to
>>>>> modernizing our indentation style in implementation files.
>>>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>>>> That will go in very soon too.
>>>>>
>>>>>
>>>>> David E DeMarle
>>>>> Kitware, Inc.
>>>>> R&D Engineer
>>>>> 21 Corporate Drive
>>>>> Clifton Park, NY 12065-8662
>>>>> Phone: 518-881-4909
>>>>>
>>>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>>>> mike.jackson at bluequartz.net> wrote:
>>>>>
>>>>>> +1 for >
>>>>>> >     /**
>>>>>> >       * Document code
>>>>>> >       * @param
>>>>>> >       */
>>>>>>
>>>>>> and leave them in the header file
>>>>>>
>>>>>> --
>>>>>> Michael A. Jackson
>>>>>> BlueQuartz Software, LLC
>>>>>> [e]: mike.jackson at bluequartz.net
>>>>>>
>>>>>>
>>>>>> David Lonie wrote:
>>>>>>
>>>>>>> One more vote for /** ... */ with leading * on lines in-between, and
>>>>>>> keeping the docs in the headers. Jumping to a header is much faster
>>>>>>> and
>>>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>>>> anyone would want to volunteer for the task of moving all the
>>>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>>>
>>>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>>>
>>>>>>>     I also prefer this doxygen style:
>>>>>>>
>>>>>>>     /**
>>>>>>>       * Document code
>>>>>>>       * @param
>>>>>>>       */
>>>>>>>
>>>>>>>     as it creates a nice header for a function that contains the
>>>>>>>     documentation.
>>>>>>>
>>>>>>>     I think documentation should stay in the header as it is part of
>>>>>>> the
>>>>>>>     interface of the module.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>>>>> often end
>>>>>>>         up in the header for the class thanks to my IDE, and having
>>>>>>> the
>>>>>>>         Doxygen there is often helpful whether the Doxygen is
>>>>>>> somewhere
>>>>>>>         on the
>>>>>>>         machine or not. I really dislike projects that put it in the
>>>>>>>         implementation, and disagree on the method names being
>>>>>>> enough. I
>>>>>>>         hope
>>>>>>>         we leave it in the headers, and for the purposes of the
>>>>>>> migration to
>>>>>>>         real Doxygen I am not sure the tools have the necessary
>>>>>>> logic to
>>>>>>>         move
>>>>>>>         documentation - just transform the style.
>>>>>>>
>>>>>>>         I prefer the
>>>>>>>
>>>>>>>         /**
>>>>>>>           * Document code
>>>>>>>           * @param
>>>>>>>           */
>>>>>>>
>>>>>>>         Style personally, but /// also works, never really liked the
>>>>>>> //!
>>>>>>>         but I
>>>>>>>         am sure I could adapt were that chosen.
>>>>>>>
>>>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via
>>>>>>> vtk-developers
>>>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>>>> wrote:
>>>>>>>          > Another argument for keeping all documentation in the
>>>>>>> header
>>>>>>>         files is so
>>>>>>>          > it's available in an install-tree-only situation. Some
>>>>>>> people
>>>>>>>         use VTK
>>>>>>>          > without the source tree around, and having the docs built
>>>>>>>         into the header
>>>>>>>          > files is quite nice in that scenario. If it were in the
>>>>>>> cxx
>>>>>>>         files, it
>>>>>>>          > wouldn't be available to such users.
>>>>>>>          >
>>>>>>>          >
>>>>>>>          > David
>>>>>>>          >
>>>>>>>          >
>>>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware
>>>>>>> .com>>
>>>>>>>          > wrote:
>>>>>>>          >
>>>>>>>          > Hi Andrew,
>>>>>>>          >
>>>>>>>          > ...
>>>>>>>          >
>>>>>>>          > For what it is worth, I also believe that documentation
>>>>>>>         should be with the
>>>>>>>          > declaration simply because the header files are the ones
>>>>>>>         people tend to
>>>>>>>          > first look at not the definition. This is what VTK
>>>>>>> currently
>>>>>>>         does. ...
>>>>>>>          >
>>>>>>>          >
>>>>>>>          > I think that moving method (not class) documentation out
>>>>>>> of
>>>>>>>         the headers
>>>>>>>          > makes the headers much more terse and legible. For the
>>>>>>> vast
>>>>>>>         majority of
>>>>>>>          > classes, the method names themselves are enough
>>>>>>>         documentation. In cases
>>>>>>>          > where method names are not enough, it is nice to have the
>>>>>>>         implementation
>>>>>>>          > nearby. Methods with inline or macro-generated
>>>>>>>         implementations would still
>>>>>>>          > have documentation in the header, as would enums.
>>>>>>>          >
>>>>>>>          >     David
>>>>>>>          >
>>>>>>>          > _______________________________________________
>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>          >
>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>         <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 <
>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>>          >
>>>>>>>          > Search the list archives at:
>>>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>>>          >
>>>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>          >
>>>>>>>          >
>>>>>>>          > _______________________________________________
>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>          >
>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>          >
>>>>>>>          > Search the list archives at:
>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>         >
>>>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>>>          > http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>>         >
>>>>>>>         >
>>>>>>>         _______________________________________________
>>>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>
>>>>>>>         Visit other Kitware open-source projects at
>>>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>
>>>>>>>         Search the list archives at:
>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>
>>>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>
>>>>>>>     Visit other Kitware open-source projects at
>>>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>>>     <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 <http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>> >
>>>>>>>
>>>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>>>> vtkusers
>>>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>>>
>>>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>
>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>
>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Search the list archives at: http://markmail.org/search/?q=
>>>> vtk-developers
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/6b296d83/attachment-0001.html>

From david.gobbi at gmail.com  Tue Sep 20 16:33:33 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Tue, 20 Sep 2016 14:33:33 -0600
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANjZAi_eX9ypd+PphW6h43LmdbC3A0BwJZi1kM9K4dtWu_Vwdg@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
 <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
 <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>
 <CANjZAi_eX9ypd+PphW6h43LmdbC3A0BwJZi1kM9K4dtWu_Vwdg@mail.gmail.com>
Message-ID: <CANwS1=EiMm8ezEz42b_mTGHm4aNHC20ZmfWZ3UD-tH6E5hFzDQ@mail.gmail.com>

Regarding the group markings, be careful when removing them, because
removing them will cause doxygen to change the order in which the methods
are displayed (I seem to recall that ungrouped methods are either all
displayed at the top or all displayed at the bottom or somesuch).  I might
even recommend that you leave them all in.

On Tue, Sep 20, 2016 at 2:07 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Sounds like a plan.
>
> I'll address Berk's and Dan's suggestions then hand off to you.
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Sep 20, 2016 at 4:00 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Dave,
>>
>> Probably the easiest thing is if you tell me when you're ready to merge
>> the doxygen change, and then I'll use that as a base for the brace change
>> MR (i.e. I'll re-run my script).  Then when the regenerated brace-change MR
>> is merged into VTK, the doxygen change will go with it.
>>
>> We obviously cannot merge the brace-change MR into the doxyen MR or vice
>> versa... there would be thousands of conflicts.  These kind of changes have
>> to be serial.
>>
>>  - David
>>
>> On Tue, Sep 20, 2016 at 1:27 PM, David E DeMarle <
>> dave.demarle at kitware.com> wrote:
>>
>>> Had been planing on this one day and then the indents the next, but sure
>>> we can merge this into that branch first or the other way around.
>>>
>>> Then we'll all just have a single merge commit to jump over rather than
>>> two.
>>>
>>> I can take a stab at the groups with a better condition here: 547
>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>
>>>
>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
>>> wrote:
>>>
>>>> That seems to generate a lot of unnecessary group ( //@{ ) markings.
>>>> Isn't there a way of avoiding that? Also, I thought that this was going to
>>>> be merged together with the indentation changes to avoid multiple conflicts?
>>>>
>>>> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <
>>>> dave.demarle at kitware.com> wrote:
>>>>
>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>
>>>>> Pending test failures I'll merge Wednesday or Thursday evening.
>>>>>
>>>>>
>>>>> David E DeMarle
>>>>> Kitware, Inc.
>>>>> R&D Engineer
>>>>> 21 Corporate Drive
>>>>> Clifton Park, NY 12065-8662
>>>>> Phone: 518-881-4909
>>>>>
>>>>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>>>>> dave.demarle at kitware.com> wrote:
>>>>>
>>>>>> I count 9 votes for /** to 5 (including my own) for /// and none for
>>>>>> /*! or //!.
>>>>>>
>>>>>> I'll go with this then:
>>>>>> /**
>>>>>>      something
>>>>>>      blah blah blah
>>>>>> */
>>>>>>
>>>>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>> and on Thursday.
>>>>>>
>>>>>> Note
>>>>>>
>>>>>> David Gobbi has another big style change coming that is going to
>>>>>> modernizing our indentation style in implementation files.
>>>>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>>>>> That will go in very soon too.
>>>>>>
>>>>>>
>>>>>> David E DeMarle
>>>>>> Kitware, Inc.
>>>>>> R&D Engineer
>>>>>> 21 Corporate Drive
>>>>>> Clifton Park, NY 12065-8662
>>>>>> Phone: 518-881-4909
>>>>>>
>>>>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>>>>> mike.jackson at bluequartz.net> wrote:
>>>>>>
>>>>>>> +1 for >
>>>>>>> >     /**
>>>>>>> >       * Document code
>>>>>>> >       * @param
>>>>>>> >       */
>>>>>>>
>>>>>>> and leave them in the header file
>>>>>>>
>>>>>>> --
>>>>>>> Michael A. Jackson
>>>>>>> BlueQuartz Software, LLC
>>>>>>> [e]: mike.jackson at bluequartz.net
>>>>>>>
>>>>>>>
>>>>>>> David Lonie wrote:
>>>>>>>
>>>>>>>> One more vote for /** ... */ with leading * on lines in-between, and
>>>>>>>> keeping the docs in the headers. Jumping to a header is much faster
>>>>>>>> and
>>>>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>>>>> anyone would want to volunteer for the task of moving all the
>>>>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>>>>
>>>>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>>>>
>>>>>>>>     I also prefer this doxygen style:
>>>>>>>>
>>>>>>>>     /**
>>>>>>>>       * Document code
>>>>>>>>       * @param
>>>>>>>>       */
>>>>>>>>
>>>>>>>>     as it creates a nice header for a function that contains the
>>>>>>>>     documentation.
>>>>>>>>
>>>>>>>>     I think documentation should stay in the header as it is part
>>>>>>>> of the
>>>>>>>>     interface of the module.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>>>>>> often end
>>>>>>>>         up in the header for the class thanks to my IDE, and having
>>>>>>>> the
>>>>>>>>         Doxygen there is often helpful whether the Doxygen is
>>>>>>>> somewhere
>>>>>>>>         on the
>>>>>>>>         machine or not. I really dislike projects that put it in the
>>>>>>>>         implementation, and disagree on the method names being
>>>>>>>> enough. I
>>>>>>>>         hope
>>>>>>>>         we leave it in the headers, and for the purposes of the
>>>>>>>> migration to
>>>>>>>>         real Doxygen I am not sure the tools have the necessary
>>>>>>>> logic to
>>>>>>>>         move
>>>>>>>>         documentation - just transform the style.
>>>>>>>>
>>>>>>>>         I prefer the
>>>>>>>>
>>>>>>>>         /**
>>>>>>>>           * Document code
>>>>>>>>           * @param
>>>>>>>>           */
>>>>>>>>
>>>>>>>>         Style personally, but /// also works, never really liked
>>>>>>>> the //!
>>>>>>>>         but I
>>>>>>>>         am sure I could adapt were that chosen.
>>>>>>>>
>>>>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via
>>>>>>>> vtk-developers
>>>>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>>>>> wrote:
>>>>>>>>          > Another argument for keeping all documentation in the
>>>>>>>> header
>>>>>>>>         files is so
>>>>>>>>          > it's available in an install-tree-only situation. Some
>>>>>>>> people
>>>>>>>>         use VTK
>>>>>>>>          > without the source tree around, and having the docs built
>>>>>>>>         into the header
>>>>>>>>          > files is quite nice in that scenario. If it were in the
>>>>>>>> cxx
>>>>>>>>         files, it
>>>>>>>>          > wouldn't be available to such users.
>>>>>>>>          >
>>>>>>>>          >
>>>>>>>>          > David
>>>>>>>>          >
>>>>>>>>          >
>>>>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware
>>>>>>>> .com>>
>>>>>>>>          > wrote:
>>>>>>>>          >
>>>>>>>>          > Hi Andrew,
>>>>>>>>          >
>>>>>>>>          > ...
>>>>>>>>          >
>>>>>>>>          > For what it is worth, I also believe that documentation
>>>>>>>>         should be with the
>>>>>>>>          > declaration simply because the header files are the ones
>>>>>>>>         people tend to
>>>>>>>>          > first look at not the definition. This is what VTK
>>>>>>>> currently
>>>>>>>>         does. ...
>>>>>>>>          >
>>>>>>>>          >
>>>>>>>>          > I think that moving method (not class) documentation out
>>>>>>>> of
>>>>>>>>         the headers
>>>>>>>>          > makes the headers much more terse and legible. For the
>>>>>>>> vast
>>>>>>>>         majority of
>>>>>>>>          > classes, the method names themselves are enough
>>>>>>>>         documentation. In cases
>>>>>>>>          > where method names are not enough, it is nice to have the
>>>>>>>>         implementation
>>>>>>>>          > nearby. Methods with inline or macro-generated
>>>>>>>>         implementations would still
>>>>>>>>          > have documentation in the header, as would enums.
>>>>>>>>          >
>>>>>>>>          >     David
>>>>>>>>          >
>>>>>>>>          > _______________________________________________
>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>          >
>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>         <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 <
>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>>>          >
>>>>>>>>          > Search the list archives at:
>>>>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>>>>          >
>>>>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>          >
>>>>>>>>          >
>>>>>>>>          > _______________________________________________
>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>          >
>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>          >
>>>>>>>>          > Search the list archives at:
>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>         >
>>>>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>>>>          > http://public.kitware.com/mail
>>>>>>>> man/listinfo/vtk-developers
>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>>>         >
>>>>>>>>         >
>>>>>>>>         _______________________________________________
>>>>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>
>>>>>>>>         Visit other Kitware open-source projects at
>>>>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>
>>>>>>>>         Search the list archives at:
>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>
>>>>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>
>>>>>>>>     Visit other Kitware open-source projects at
>>>>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>>>>     <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 <http://www.vtk.org/Wiki/VTK_F
>>>>>>>> AQ>
>>>>>>>>
>>>>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>>>>> vtkusers
>>>>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>>>>
>>>>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>
>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>> vtk-developers
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160920/c353f785/attachment-0001.html>

From frank.heimes at live.de  Wed Sep 21 05:17:11 2016
From: frank.heimes at live.de (FrankHeimes)
Date: Wed, 21 Sep 2016 02:17:11 -0700 (MST)
Subject: [vtk-developers] CMake forgets to configure gl2ps for the
	vtkRenderingOpenGL backend
Message-ID: <1474449431460-5740470.post@n5.nabble.com>

I'm building VTK 6.3 using CMake 3.5.2 and Visual Studio 2015 on Windows.

The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL2
succeeds with no problems. However, we need to stick to OpenGL and avoid
dependencies on OpenGL2 features.

The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL  fails
with two unsatisfied dependencies:
CMake Error at CMake/vtkModuleAPI.cmake:120 (message):
  Requested modules not available:
    vtkRenderingGL2PS
    vtkgl2ps

According to
http://vtk.1045678.n5.nabble.com/Adding-GL2PS-as-a-RenderingOpenGL-dependency-td5719546.html,
David has obviously added these dependencies to the OpenGL rendering
backend.

The sources for the gl2ps library and make inputs are apparently available,
but cmake doesn't create projects to build them and satisfy the above
dependencies:
	ThirdParty\gl2ps\CMakeLists.txt
	ThirdParty\gl2ps\module.cmake
	ThirdParty\gl2ps\vtkgl2ps\CMakeLists.txt
	ThirdParty\gl2ps\vtkgl2ps\gl2ps.c
	ThirdParty\gl2ps\vtkgl2ps\gl2ps.h
	ThirdParty\gl2ps\vtk_gl2ps.h.in

I already tried to add -DVTK_USE_GL2PS:BOOL=ON as someone proposed in
another post, but to no avail.

We don't care for postscript export. The only thing we need is NO
dependencies on OpenGL2 features.



--
View this message in context: http://vtk.1045678.n5.nabble.com/CMake-forgets-to-configure-gl2ps-for-the-vtkRenderingOpenGL-backend-tp5740470.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From dave.demarle at kitware.com  Wed Sep 21 10:29:23 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Wed, 21 Sep 2016 10:29:23 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANwS1=EiMm8ezEz42b_mTGHm4aNHC20ZmfWZ3UD-tH6E5hFzDQ@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
 <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
 <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>
 <CANjZAi_eX9ypd+PphW6h43LmdbC3A0BwJZi1kM9K4dtWu_Vwdg@mail.gmail.com>
 <CANwS1=EiMm8ezEz42b_mTGHm4aNHC20ZmfWZ3UD-tH6E5hFzDQ@mail.gmail.com>
Message-ID: <CANjZAi8EEJH8kAgKpptrTssjw6kWiG6v4WvK9hWM-h4Bo6Rkfg@mail.gmail.com>

@Berk and @David

I made a small change to the script that improves things substantially.
I can think of cases where it still puts single items inside a group, but
we can take those out manually after the fact.



David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Sep 20, 2016 at 4:33 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Regarding the group markings, be careful when removing them, because
> removing them will cause doxygen to change the order in which the methods
> are displayed (I seem to recall that ungrouped methods are either all
> displayed at the top or all displayed at the bottom or somesuch).  I might
> even recommend that you leave them all in.
>
> On Tue, Sep 20, 2016 at 2:07 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> Sounds like a plan.
>>
>> I'll address Berk's and Dan's suggestions then hand off to you.
>>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Tue, Sep 20, 2016 at 4:00 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>>> Dave,
>>>
>>> Probably the easiest thing is if you tell me when you're ready to merge
>>> the doxygen change, and then I'll use that as a base for the brace change
>>> MR (i.e. I'll re-run my script).  Then when the regenerated brace-change MR
>>> is merged into VTK, the doxygen change will go with it.
>>>
>>> We obviously cannot merge the brace-change MR into the doxyen MR or vice
>>> versa... there would be thousands of conflicts.  These kind of changes have
>>> to be serial.
>>>
>>>  - David
>>>
>>> On Tue, Sep 20, 2016 at 1:27 PM, David E DeMarle <
>>> dave.demarle at kitware.com> wrote:
>>>
>>>> Had been planing on this one day and then the indents the next, but
>>>> sure we can merge this into that branch first or the other way around.
>>>>
>>>> Then we'll all just have a single merge commit to jump over rather than
>>>> two.
>>>>
>>>> I can take a stab at the groups with a better condition here: 547
>>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>>
>>>>
>>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>>
>>>>
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909
>>>>
>>>> On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
>>>> wrote:
>>>>
>>>>> That seems to generate a lot of unnecessary group ( //@{ ) markings.
>>>>> Isn't there a way of avoiding that? Also, I thought that this was going to
>>>>> be merged together with the indentation changes to avoid multiple conflicts?
>>>>>
>>>>> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <
>>>>> dave.demarle at kitware.com> wrote:
>>>>>
>>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>>
>>>>>> Pending test failures I'll merge Wednesday or Thursday evening.
>>>>>>
>>>>>>
>>>>>> David E DeMarle
>>>>>> Kitware, Inc.
>>>>>> R&D Engineer
>>>>>> 21 Corporate Drive
>>>>>> Clifton Park, NY 12065-8662
>>>>>> Phone: 518-881-4909
>>>>>>
>>>>>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>>>>>> dave.demarle at kitware.com> wrote:
>>>>>>
>>>>>>> I count 9 votes for /** to 5 (including my own) for /// and none for
>>>>>>> /*! or //!.
>>>>>>>
>>>>>>> I'll go with this then:
>>>>>>> /**
>>>>>>>      something
>>>>>>>      blah blah blah
>>>>>>> */
>>>>>>>
>>>>>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>>> and on Thursday.
>>>>>>>
>>>>>>> Note
>>>>>>>
>>>>>>> David Gobbi has another big style change coming that is going to
>>>>>>> modernizing our indentation style in implementation files.
>>>>>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>>>>>> That will go in very soon too.
>>>>>>>
>>>>>>>
>>>>>>> David E DeMarle
>>>>>>> Kitware, Inc.
>>>>>>> R&D Engineer
>>>>>>> 21 Corporate Drive
>>>>>>> Clifton Park, NY 12065-8662
>>>>>>> Phone: 518-881-4909
>>>>>>>
>>>>>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>>>>>> mike.jackson at bluequartz.net> wrote:
>>>>>>>
>>>>>>>> +1 for >
>>>>>>>> >     /**
>>>>>>>> >       * Document code
>>>>>>>> >       * @param
>>>>>>>> >       */
>>>>>>>>
>>>>>>>> and leave them in the header file
>>>>>>>>
>>>>>>>> --
>>>>>>>> Michael A. Jackson
>>>>>>>> BlueQuartz Software, LLC
>>>>>>>> [e]: mike.jackson at bluequartz.net
>>>>>>>>
>>>>>>>>
>>>>>>>> David Lonie wrote:
>>>>>>>>
>>>>>>>>> One more vote for /** ... */ with leading * on lines in-between,
>>>>>>>>> and
>>>>>>>>> keeping the docs in the headers. Jumping to a header is much
>>>>>>>>> faster and
>>>>>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>>>>>> anyone would want to volunteer for the task of moving all the
>>>>>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>>>>>
>>>>>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>>>>>
>>>>>>>>>     I also prefer this doxygen style:
>>>>>>>>>
>>>>>>>>>     /**
>>>>>>>>>       * Document code
>>>>>>>>>       * @param
>>>>>>>>>       */
>>>>>>>>>
>>>>>>>>>     as it creates a nice header for a function that contains the
>>>>>>>>>     documentation.
>>>>>>>>>
>>>>>>>>>     I think documentation should stay in the header as it is part
>>>>>>>>> of the
>>>>>>>>>     interface of the module.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>         The Doxygen isn't always there, when I am hunting issues I
>>>>>>>>> often end
>>>>>>>>>         up in the header for the class thanks to my IDE, and
>>>>>>>>> having the
>>>>>>>>>         Doxygen there is often helpful whether the Doxygen is
>>>>>>>>> somewhere
>>>>>>>>>         on the
>>>>>>>>>         machine or not. I really dislike projects that put it in
>>>>>>>>> the
>>>>>>>>>         implementation, and disagree on the method names being
>>>>>>>>> enough. I
>>>>>>>>>         hope
>>>>>>>>>         we leave it in the headers, and for the purposes of the
>>>>>>>>> migration to
>>>>>>>>>         real Doxygen I am not sure the tools have the necessary
>>>>>>>>> logic to
>>>>>>>>>         move
>>>>>>>>>         documentation - just transform the style.
>>>>>>>>>
>>>>>>>>>         I prefer the
>>>>>>>>>
>>>>>>>>>         /**
>>>>>>>>>           * Document code
>>>>>>>>>           * @param
>>>>>>>>>           */
>>>>>>>>>
>>>>>>>>>         Style personally, but /// also works, never really liked
>>>>>>>>> the //!
>>>>>>>>>         but I
>>>>>>>>>         am sure I could adapt were that chosen.
>>>>>>>>>
>>>>>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via
>>>>>>>>> vtk-developers
>>>>>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>>>>>> wrote:
>>>>>>>>>          > Another argument for keeping all documentation in the
>>>>>>>>> header
>>>>>>>>>         files is so
>>>>>>>>>          > it's available in an install-tree-only situation. Some
>>>>>>>>> people
>>>>>>>>>         use VTK
>>>>>>>>>          > without the source tree around, and having the docs
>>>>>>>>> built
>>>>>>>>>         into the header
>>>>>>>>>          > files is quite nice in that scenario. If it were in the
>>>>>>>>> cxx
>>>>>>>>>         files, it
>>>>>>>>>          > wouldn't be available to such users.
>>>>>>>>>          >
>>>>>>>>>          >
>>>>>>>>>          > David
>>>>>>>>>          >
>>>>>>>>>          >
>>>>>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>>>>>         <david.thompson at kitware.com <mailto:david.thompson at kitware
>>>>>>>>> .com>>
>>>>>>>>>          > wrote:
>>>>>>>>>          >
>>>>>>>>>          > Hi Andrew,
>>>>>>>>>          >
>>>>>>>>>          > ...
>>>>>>>>>          >
>>>>>>>>>          > For what it is worth, I also believe that documentation
>>>>>>>>>         should be with the
>>>>>>>>>          > declaration simply because the header files are the ones
>>>>>>>>>         people tend to
>>>>>>>>>          > first look at not the definition. This is what VTK
>>>>>>>>> currently
>>>>>>>>>         does. ...
>>>>>>>>>          >
>>>>>>>>>          >
>>>>>>>>>          > I think that moving method (not class) documentation
>>>>>>>>> out of
>>>>>>>>>         the headers
>>>>>>>>>          > makes the headers much more terse and legible. For the
>>>>>>>>> vast
>>>>>>>>>         majority of
>>>>>>>>>          > classes, the method names themselves are enough
>>>>>>>>>         documentation. In cases
>>>>>>>>>          > where method names are not enough, it is nice to have
>>>>>>>>> the
>>>>>>>>>         implementation
>>>>>>>>>          > nearby. Methods with inline or macro-generated
>>>>>>>>>         implementations would still
>>>>>>>>>          > have documentation in the header, as would enums.
>>>>>>>>>          >
>>>>>>>>>          >     David
>>>>>>>>>          >
>>>>>>>>>          > _______________________________________________
>>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>          >
>>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>>         <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 <
>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>>>>          >
>>>>>>>>>          > Search the list archives at:
>>>>>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>>>>>          >
>>>>>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>>          >
>>>>>>>>>          >
>>>>>>>>>          > _______________________________________________
>>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>          >
>>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>>          >
>>>>>>>>>          > Search the list archives at:
>>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>>         >
>>>>>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>>>>>          > http://public.kitware.com/mail
>>>>>>>>> man/listinfo/vtk-developers
>>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>> >
>>>>>>>>>         >
>>>>>>>>>         >
>>>>>>>>>         _______________________________________________
>>>>>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>
>>>>>>>>>         Visit other Kitware open-source projects at
>>>>>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>>
>>>>>>>>>         Search the list archives at:
>>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>>
>>>>>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     _______________________________________________
>>>>>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>
>>>>>>>>>     Visit other Kitware open-source projects at
>>>>>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>>>>>     <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 <http://www.vtk.org/Wiki/VTK_F
>>>>>>>>> AQ>
>>>>>>>>>
>>>>>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>>>>>> vtkusers
>>>>>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>>>>>
>>>>>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>
>>>>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>>>>> vtkusers
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>> vtk-developers
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160921/296cdebf/attachment-0001.html>

From berk.geveci at kitware.com  Wed Sep 21 10:32:18 2016
From: berk.geveci at kitware.com (Berk Geveci)
Date: Wed, 21 Sep 2016 10:32:18 -0400
Subject: [vtk-developers] [vtkusers] poll - vtk doxygen style
In-Reply-To: <CANjZAi8EEJH8kAgKpptrTssjw6kWiG6v4WvK9hWM-h4Bo6Rkfg@mail.gmail.com>
References: <CAHDsG9Pr8ebZW92RksMpqxzq1-ZG=-KZPvb8JurGmjmjW7qdGg@mail.gmail.com>
 <DCB3FB8C-4CFE-495E-9BA3-0472429E171D@kitware.com>
 <6BC20FED-43A4-4C0D-AE68-84F6CD8E20AD@aol.com>
 <CAMkPkZX=t1gMnZe5Koi2pxCBhCO4hUdk1wqThH_eiFNtVg-vXQ@mail.gmail.com>
 <CADwGrVoBNXwm0XnqLdozPTQn-neJzFgX2p2rAPikT5e2VJW0mw@mail.gmail.com>
 <CA+=e1ovEtjxgheUNJdMF52gfkY9ov0ZKuGH7SqqHkfijnkOZVg@mail.gmail.com>
 <57E03C30.5010803@bluequartz.net>
 <CANjZAi-=m-OhiXeYrJBqKQ0kkHVwRESRUnVV6eLGUAjJeCF07w@mail.gmail.com>
 <CANjZAi8yDtNU_Oan9=S-d--rSvMVYW4Hf1R4T1mkm-AyawKb0w@mail.gmail.com>
 <CAE32kpUOutzjgvTE5Y5gL9bSaTJrZ9gaOTiic-8jDrxgmCAEpQ@mail.gmail.com>
 <CANjZAi-K3a9wkY9HZOuXWowqovDpdFKGhjzp7QN5ucdppEAT=w@mail.gmail.com>
 <CANwS1=GD2Zgp10EBngi7rMywrwNyHyGVjvfnJKqicb0_duUHhQ@mail.gmail.com>
 <CANjZAi_eX9ypd+PphW6h43LmdbC3A0BwJZi1kM9K4dtWu_Vwdg@mail.gmail.com>
 <CANwS1=EiMm8ezEz42b_mTGHm4aNHC20ZmfWZ3UD-tH6E5hFzDQ@mail.gmail.com>
 <CANjZAi8EEJH8kAgKpptrTssjw6kWiG6v4WvK9hWM-h4Bo6Rkfg@mail.gmail.com>
Message-ID: <CAE32kpW_5hCsTM3AjKgQPVguUgVJrt8yp_Zu1iMGQtkXm+Ruow@mail.gmail.com>

Sounds great! Thanks Dave.

On Wed, Sep 21, 2016 at 10:29 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> @Berk and @David
>
> I made a small change to the script that improves things substantially.
> I can think of cases where it still puts single items inside a group, but
> we can take those out manually after the fact.
>
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Sep 20, 2016 at 4:33 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Regarding the group markings, be careful when removing them, because
>> removing them will cause doxygen to change the order in which the methods
>> are displayed (I seem to recall that ungrouped methods are either all
>> displayed at the top or all displayed at the bottom or somesuch).  I might
>> even recommend that you leave them all in.
>>
>> On Tue, Sep 20, 2016 at 2:07 PM, David E DeMarle <
>> dave.demarle at kitware.com> wrote:
>>
>>> Sounds like a plan.
>>>
>>> I'll address Berk's and Dan's suggestions then hand off to you.
>>>
>>>
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>> On Tue, Sep 20, 2016 at 4:00 PM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>>
>>>> Dave,
>>>>
>>>> Probably the easiest thing is if you tell me when you're ready to merge
>>>> the doxygen change, and then I'll use that as a base for the brace change
>>>> MR (i.e. I'll re-run my script).  Then when the regenerated brace-change MR
>>>> is merged into VTK, the doxygen change will go with it.
>>>>
>>>> We obviously cannot merge the brace-change MR into the doxyen MR or
>>>> vice versa... there would be thousands of conflicts.  These kind of changes
>>>> have to be serial.
>>>>
>>>>  - David
>>>>
>>>> On Tue, Sep 20, 2016 at 1:27 PM, David E DeMarle <
>>>> dave.demarle at kitware.com> wrote:
>>>>
>>>>> Had been planing on this one day and then the indents the next, but
>>>>> sure we can merge this into that branch first or the other way around.
>>>>>
>>>>> Then we'll all just have a single merge commit to jump over rather
>>>>> than two.
>>>>>
>>>>> I can take a stab at the groups with a better condition here: 547
>>>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>>>
>>>>>
>>>>> <https://gitlab.kitware.com/vtk/vtk/blob/6f6b5333c8dde9b8df9dfb8d9d5bbf0500975f22/Utilities/Doxygen/doc_header2doxygen.pl#L547>
>>>>>
>>>>>
>>>>>
>>>>> David E DeMarle
>>>>> Kitware, Inc.
>>>>> R&D Engineer
>>>>> 21 Corporate Drive
>>>>> Clifton Park, NY 12065-8662
>>>>> Phone: 518-881-4909
>>>>>
>>>>> On Tue, Sep 20, 2016 at 3:10 PM, Berk Geveci <berk.geveci at kitware.com>
>>>>> wrote:
>>>>>
>>>>>> That seems to generate a lot of unnecessary group ( //@{ ) markings.
>>>>>> Isn't there a way of avoiding that? Also, I thought that this was going to
>>>>>> be merged together with the indentation changes to avoid multiple conflicts?
>>>>>>
>>>>>> On Tue, Sep 20, 2016 at 2:20 PM, David E DeMarle <
>>>>>> dave.demarle at kitware.com> wrote:
>>>>>>
>>>>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>>>
>>>>>>> Pending test failures I'll merge Wednesday or Thursday evening.
>>>>>>>
>>>>>>>
>>>>>>> David E DeMarle
>>>>>>> Kitware, Inc.
>>>>>>> R&D Engineer
>>>>>>> 21 Corporate Drive
>>>>>>> Clifton Park, NY 12065-8662
>>>>>>> Phone: 518-881-4909
>>>>>>>
>>>>>>> On Tue, Sep 20, 2016 at 8:45 AM, David E DeMarle <
>>>>>>> dave.demarle at kitware.com> wrote:
>>>>>>>
>>>>>>>> I count 9 votes for /** to 5 (including my own) for /// and none
>>>>>>>> for /*! or //!.
>>>>>>>>
>>>>>>>> I'll go with this then:
>>>>>>>> /**
>>>>>>>>      something
>>>>>>>>      blah blah blah
>>>>>>>> */
>>>>>>>>
>>>>>>>> I'll revise https://gitlab.kitware.com/vtk/vtk/merge_requests/1932
>>>>>>>> and on Thursday.
>>>>>>>>
>>>>>>>> Note
>>>>>>>>
>>>>>>>> David Gobbi has another big style change coming that is going to
>>>>>>>> modernizing our indentation style in implementation files.
>>>>>>>> See: https://gitlab.kitware.com/vtk/vtk/merge_requests/1911
>>>>>>>> That will go in very soon too.
>>>>>>>>
>>>>>>>>
>>>>>>>> David E DeMarle
>>>>>>>> Kitware, Inc.
>>>>>>>> R&D Engineer
>>>>>>>> 21 Corporate Drive
>>>>>>>> Clifton Park, NY 12065-8662
>>>>>>>> Phone: 518-881-4909
>>>>>>>>
>>>>>>>> On Mon, Sep 19, 2016 at 3:27 PM, Michael Jackson <
>>>>>>>> mike.jackson at bluequartz.net> wrote:
>>>>>>>>
>>>>>>>>> +1 for >
>>>>>>>>> >     /**
>>>>>>>>> >       * Document code
>>>>>>>>> >       * @param
>>>>>>>>> >       */
>>>>>>>>>
>>>>>>>>> and leave them in the header file
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Michael A. Jackson
>>>>>>>>> BlueQuartz Software, LLC
>>>>>>>>> [e]: mike.jackson at bluequartz.net
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> David Lonie wrote:
>>>>>>>>>
>>>>>>>>>> One more vote for /** ... */ with leading * on lines in-between,
>>>>>>>>>> and
>>>>>>>>>> keeping the docs in the headers. Jumping to a header is much
>>>>>>>>>> faster and
>>>>>>>>>> easier than opening a doxygen page with modern IDEs. Plus, I doubt
>>>>>>>>>> anyone would want to volunteer for the task of moving all the
>>>>>>>>>> docstrings, and it doesn't sound easy to script/automate.
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 19, 2016 at 9:40 AM, Dan Lipsa <dan.lipsa at kitware.com
>>>>>>>>>> <mailto:dan.lipsa at kitware.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>     I also prefer this doxygen style:
>>>>>>>>>>
>>>>>>>>>>     /**
>>>>>>>>>>       * Document code
>>>>>>>>>>       * @param
>>>>>>>>>>       */
>>>>>>>>>>
>>>>>>>>>>     as it creates a nice header for a function that contains the
>>>>>>>>>>     documentation.
>>>>>>>>>>
>>>>>>>>>>     I think documentation should stay in the header as it is part
>>>>>>>>>> of the
>>>>>>>>>>     interface of the module.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     On Mon, Sep 19, 2016 at 8:56 AM, Marcus D. Hanwell
>>>>>>>>>>     <marcus.hanwell at kitware.com <mailto:marcus.hanwell at kitware
>>>>>>>>>> .com>> wrote:
>>>>>>>>>>
>>>>>>>>>>         The Doxygen isn't always there, when I am hunting issues
>>>>>>>>>> I often end
>>>>>>>>>>         up in the header for the class thanks to my IDE, and
>>>>>>>>>> having the
>>>>>>>>>>         Doxygen there is often helpful whether the Doxygen is
>>>>>>>>>> somewhere
>>>>>>>>>>         on the
>>>>>>>>>>         machine or not. I really dislike projects that put it in
>>>>>>>>>> the
>>>>>>>>>>         implementation, and disagree on the method names being
>>>>>>>>>> enough. I
>>>>>>>>>>         hope
>>>>>>>>>>         we leave it in the headers, and for the purposes of the
>>>>>>>>>> migration to
>>>>>>>>>>         real Doxygen I am not sure the tools have the necessary
>>>>>>>>>> logic to
>>>>>>>>>>         move
>>>>>>>>>>         documentation - just transform the style.
>>>>>>>>>>
>>>>>>>>>>         I prefer the
>>>>>>>>>>
>>>>>>>>>>         /**
>>>>>>>>>>           * Document code
>>>>>>>>>>           * @param
>>>>>>>>>>           */
>>>>>>>>>>
>>>>>>>>>>         Style personally, but /// also works, never really liked
>>>>>>>>>> the //!
>>>>>>>>>>         but I
>>>>>>>>>>         am sure I could adapt were that chosen.
>>>>>>>>>>
>>>>>>>>>>         On Sat, Sep 17, 2016 at 10:37 PM, David Cole via
>>>>>>>>>> vtk-developers
>>>>>>>>>>         <vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>>>>>>>>>> wrote:
>>>>>>>>>>          > Another argument for keeping all documentation in the
>>>>>>>>>> header
>>>>>>>>>>         files is so
>>>>>>>>>>          > it's available in an install-tree-only situation. Some
>>>>>>>>>> people
>>>>>>>>>>         use VTK
>>>>>>>>>>          > without the source tree around, and having the docs
>>>>>>>>>> built
>>>>>>>>>>         into the header
>>>>>>>>>>          > files is quite nice in that scenario. If it were in
>>>>>>>>>> the cxx
>>>>>>>>>>         files, it
>>>>>>>>>>          > wouldn't be available to such users.
>>>>>>>>>>          >
>>>>>>>>>>          >
>>>>>>>>>>          > David
>>>>>>>>>>          >
>>>>>>>>>>          >
>>>>>>>>>>          > On Sep 17, 2016, at 6:47 PM, David Thompson
>>>>>>>>>>         <david.thompson at kitware.com <mailto:
>>>>>>>>>> david.thompson at kitware.com>>
>>>>>>>>>>          > wrote:
>>>>>>>>>>          >
>>>>>>>>>>          > Hi Andrew,
>>>>>>>>>>          >
>>>>>>>>>>          > ...
>>>>>>>>>>          >
>>>>>>>>>>          > For what it is worth, I also believe that documentation
>>>>>>>>>>         should be with the
>>>>>>>>>>          > declaration simply because the header files are the
>>>>>>>>>> ones
>>>>>>>>>>         people tend to
>>>>>>>>>>          > first look at not the definition. This is what VTK
>>>>>>>>>> currently
>>>>>>>>>>         does. ...
>>>>>>>>>>          >
>>>>>>>>>>          >
>>>>>>>>>>          > I think that moving method (not class) documentation
>>>>>>>>>> out of
>>>>>>>>>>         the headers
>>>>>>>>>>          > makes the headers much more terse and legible. For the
>>>>>>>>>> vast
>>>>>>>>>>         majority of
>>>>>>>>>>          > classes, the method names themselves are enough
>>>>>>>>>>         documentation. In cases
>>>>>>>>>>          > where method names are not enough, it is nice to have
>>>>>>>>>> the
>>>>>>>>>>         implementation
>>>>>>>>>>          > nearby. Methods with inline or macro-generated
>>>>>>>>>>         implementations would still
>>>>>>>>>>          > have documentation in the header, as would enums.
>>>>>>>>>>          >
>>>>>>>>>>          >     David
>>>>>>>>>>          >
>>>>>>>>>>          > _______________________________________________
>>>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>>          >
>>>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>         <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 <
>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>>>>>          >
>>>>>>>>>>          > Search the list archives at:
>>>>>>>>>>         http://markmail.org/search/?q=vtkusers
>>>>>>>>>>         <http://markmail.org/search/?q=vtkusers>
>>>>>>>>>>          >
>>>>>>>>>>          > Follow this link to subscribe/unsubscribe:
>>>>>>>>>>          > http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>>         <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>>>          >
>>>>>>>>>>          >
>>>>>>>>>>          > _______________________________________________
>>>>>>>>>>          > Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>>          >
>>>>>>>>>>          > Visit other Kitware open-source projects at
>>>>>>>>>>          > http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>>>          >
>>>>>>>>>>          > Search the list archives at:
>>>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>>>         >
>>>>>>>>>>         >  Follow this link to subscribe/unsubscribe:
>>>>>>>>>>          > http://public.kitware.com/mail
>>>>>>>>>> man/listinfo/vtk-developers
>>>>>>>>>>         <http://public.kitware.com/mai
>>>>>>>>>> lman/listinfo/vtk-developers>
>>>>>>>>>>         >
>>>>>>>>>>         >
>>>>>>>>>>         _______________________________________________
>>>>>>>>>>         Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>>
>>>>>>>>>>         Visit other Kitware open-source projects at
>>>>>>>>>>         http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>         <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>>>
>>>>>>>>>>         Search the list archives at:
>>>>>>>>>>         http://markmail.org/search/?q=vtk-developers
>>>>>>>>>>         <http://markmail.org/search/?q=vtk-developers>
>>>>>>>>>>
>>>>>>>>>>         Follow this link to subscribe/unsubscribe:
>>>>>>>>>>         http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>>>>         <http://public.kitware.com/mai
>>>>>>>>>> lman/listinfo/vtk-developers>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     _______________________________________________
>>>>>>>>>>     Powered by www.kitware.com <http://www.kitware.com>
>>>>>>>>>>
>>>>>>>>>>     Visit other Kitware open-source projects at
>>>>>>>>>>     http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>     <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 <
>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ>
>>>>>>>>>>
>>>>>>>>>>     Search the list archives at: http://markmail.org/search/?q=
>>>>>>>>>> vtkusers
>>>>>>>>>>     <http://markmail.org/search/?q=vtkusers>
>>>>>>>>>>
>>>>>>>>>>     Follow this link to subscribe/unsubscribe:
>>>>>>>>>>     http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>>     <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>>
>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>>
>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>>
>>>>>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>>>>>> vtkusers
>>>>>>>>>>
>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>
>>>>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>>>>> vtkusers
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>>
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>
>>>>>>> Search the list archives at: http://markmail.org/search/?q=
>>>>>>> vtk-developers
>>>>>>>
>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160921/f20fa23a/attachment-0001.html>

From dan.lipsa at kitware.com  Thu Sep 22 10:39:10 2016
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Thu, 22 Sep 2016 10:39:10 -0400
Subject: [vtk-developers] Wiki examples baselines
Message-ID: <CADwGrVqoD6qDKwxxZ8jmiJ0T70iwnpNWjoM9zfSG1f4kxLaPWQ@mail.gmail.com>

Hi Bill and all,
I merged in a branch that improved label placement
https://gitlab.kitware.com/vtk/vtk/merge_requests/1925

and this broke 10 wiki examples.

https://open.cdash.org/viewTest.php?onlyfailed&buildid=4561670

How do I update the baselines for those?
Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160922/4abc4676/attachment.html>

From bill.lorensen at gmail.com  Thu Sep 22 11:25:49 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Sep 2016 11:25:49 -0400
Subject: [vtk-developers] Wiki examples baselines
In-Reply-To: <CADwGrVqoD6qDKwxxZ8jmiJ0T70iwnpNWjoM9zfSG1f4kxLaPWQ@mail.gmail.com>
References: <CADwGrVqoD6qDKwxxZ8jmiJ0T70iwnpNWjoM9zfSG1f4kxLaPWQ@mail.gmail.com>
Message-ID: <CADZJ4hMAJNq0mFFO=F1NyxFKOEm42TFEuWNsQ97HKFK+wcX51w@mail.gmail.com>

Dan,

I'll have to do that for now.

Thanks,

Bill

On Thu, Sep 22, 2016 at 10:39 AM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
> Hi Bill and all,
> I merged in a branch that improved label placement
> https://gitlab.kitware.com/vtk/vtk/merge_requests/1925
>
> and this broke 10 wiki examples.
>
> https://open.cdash.org/viewTest.php?onlyfailed&buildid=4561670
>
> How do I update the baselines for those?
> Thanks,
> Dan
>



-- 
Unpaid intern in BillsBasement at noware dot com

From dan.lipsa at kitware.com  Thu Sep 22 11:39:29 2016
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Thu, 22 Sep 2016 11:39:29 -0400
Subject: [vtk-developers] Wiki examples baselines
In-Reply-To: <CADZJ4hMAJNq0mFFO=F1NyxFKOEm42TFEuWNsQ97HKFK+wcX51w@mail.gmail.com>
References: <CADwGrVqoD6qDKwxxZ8jmiJ0T70iwnpNWjoM9zfSG1f4kxLaPWQ@mail.gmail.com>
 <CADZJ4hMAJNq0mFFO=F1NyxFKOEm42TFEuWNsQ97HKFK+wcX51w@mail.gmail.com>
Message-ID: <CADwGrVo072Fta75NyjOYALDJmJhohJ15ZpPajJv_DVmHD4Gb4g@mail.gmail.com>

Thanks Bill.

Dan


On Thu, Sep 22, 2016 at 11:25 AM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Dan,
>
> I'll have to do that for now.
>
> Thanks,
>
> Bill
>
> On Thu, Sep 22, 2016 at 10:39 AM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
> > Hi Bill and all,
> > I merged in a branch that improved label placement
> > https://gitlab.kitware.com/vtk/vtk/merge_requests/1925
> >
> > and this broke 10 wiki examples.
> >
> > https://open.cdash.org/viewTest.php?onlyfailed&buildid=4561670
> >
> > How do I update the baselines for those?
> > Thanks,
> > Dan
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160922/dd056ad7/attachment.html>

From bill.lorensen at gmail.com  Thu Sep 22 14:45:42 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Sep 2016 14:45:42 -0400
Subject: [vtk-developers] Wiki examples baselines
In-Reply-To: <CADwGrVo072Fta75NyjOYALDJmJhohJ15ZpPajJv_DVmHD4Gb4g@mail.gmail.com>
References: <CADwGrVqoD6qDKwxxZ8jmiJ0T70iwnpNWjoM9zfSG1f4kxLaPWQ@mail.gmail.com>
 <CADZJ4hMAJNq0mFFO=F1NyxFKOEm42TFEuWNsQ97HKFK+wcX51w@mail.gmail.com>
 <CADwGrVo072Fta75NyjOYALDJmJhohJ15ZpPajJv_DVmHD4Gb4g@mail.gmail.com>
Message-ID: <CADZJ4hNhj+abngtCZyOQ9+nh4AwvXXSQJG6PXqcV2+9fvoRVFg@mail.gmail.com>

Dan,

I updated the baselines. We'll see tomorrow.

Thanks

On Thu, Sep 22, 2016 at 11:39 AM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
> Thanks Bill.
>
> Dan
>
>
> On Thu, Sep 22, 2016 at 11:25 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> Dan,
>>
>> I'll have to do that for now.
>>
>> Thanks,
>>
>> Bill
>>
>> On Thu, Sep 22, 2016 at 10:39 AM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>> > Hi Bill and all,
>> > I merged in a branch that improved label placement
>> > https://gitlab.kitware.com/vtk/vtk/merge_requests/1925
>> >
>> > and this broke 10 wiki examples.
>> >
>> > https://open.cdash.org/viewTest.php?onlyfailed&buildid=4561670
>> >
>> > How do I update the baselines for those?
>> > Thanks,
>> > Dan
>> >
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From david.gobbi at gmail.com  Thu Sep 22 15:29:35 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 22 Sep 2016 13:29:35 -0600
Subject: [vtk-developers] Adding NaN check causes SLACParticleReader test to
	fail
Message-ID: <CANwS1=ENVu0gNF2c-XT7zhmRiLYtx0+WCT5e49cTvkAYh5u2tQ@mail.gmail.com>

Hi Ken,

I have this test failure after adding a NaN check for log lookup tables:

http://open.cdash.org/testDetails.php?test=485375551&build=4562944

Should the test be modified to produce fewer NaNs, or is it okay if I just
create a new baseline image?

Thanks,
 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160922/01abeb7f/attachment.html>

From kmorel at sandia.gov  Thu Sep 22 15:36:41 2016
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Thu, 22 Sep 2016 19:36:41 +0000
Subject: [vtk-developers] [EXTERNAL] Adding NaN check causes
 SLACParticleReader test to fail
In-Reply-To: <CANwS1=ENVu0gNF2c-XT7zhmRiLYtx0+WCT5e49cTvkAYh5u2tQ@mail.gmail.com>
References: <CANwS1=ENVu0gNF2c-XT7zhmRiLYtx0+WCT5e49cTvkAYh5u2tQ@mail.gmail.com>
Message-ID: <ae95da513e2e4fff9da15e82356590a9@ES08AMSNLNT.srn.sandia.gov>

The new image looks correct. Those data have a lot of NaN values for parts of the mesh away from the particles, so assuming the marroon color is the NaN color, the new image is what I would expect. I would create a new baseline image.

-Ken

From: David Gobbi [mailto:david.gobbi at gmail.com]
Sent: Thursday, September 22, 2016 1:30 PM
To: Moreland, Kenneth <kmorel at sandia.gov>; VTK Developers <vtk-developers at vtk.org>
Subject: [EXTERNAL] Adding NaN check causes SLACParticleReader test to fail

Hi Ken,

I have this test failure after adding a NaN check for log lookup tables:

http://open.cdash.org/testDetails.php?test=485375551&build=4562944

Should the test be modified to produce fewer NaNs, or is it okay if I just create a new baseline image?

Thanks,
 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160922/893bddfa/attachment.html>

From david.gobbi at gmail.com  Thu Sep 22 15:45:26 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Thu, 22 Sep 2016 13:45:26 -0600
Subject: [vtk-developers] [EXTERNAL] Adding NaN check causes
	SLACParticleReader test to fail
In-Reply-To: <ae95da513e2e4fff9da15e82356590a9@ES08AMSNLNT.srn.sandia.gov>
References: <CANwS1=ENVu0gNF2c-XT7zhmRiLYtx0+WCT5e49cTvkAYh5u2tQ@mail.gmail.com>
 <ae95da513e2e4fff9da15e82356590a9@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <CANwS1=ECHdC+XEVqjedDb9hJZAP8+i14u0Bc2KCiK7AibVF15w@mail.gmail.com>

Awesome.  Good to know that the result is as expected.

 - David

On Thu, Sep 22, 2016 at 1:36 PM, Moreland, Kenneth <kmorel at sandia.gov>
wrote:

> The new image looks correct. Those data have a lot of NaN values for parts
> of the mesh away from the particles, so assuming the marroon color is the
> NaN color, the new image is what I would expect. I would create a new
> baseline image.
>
>
>
> -Ken
>
>
>
> *From:* David Gobbi [mailto:david.gobbi at gmail.com]
> *Sent:* Thursday, September 22, 2016 1:30 PM
> *To:* Moreland, Kenneth <kmorel at sandia.gov>; VTK Developers <
> vtk-developers at vtk.org>
> *Subject:* [EXTERNAL] Adding NaN check causes SLACParticleReader test to
> fail
>
>
>
> Hi Ken,
>
>
>
> I have this test failure after adding a NaN check for log lookup tables:
>
>
>
> http://open.cdash.org/testDetails.php?test=485375551&build=4562944
>
>
>
> Should the test be modified to produce fewer NaNs, or is it okay if I just
> create a new baseline image?
>
>
>
> Thanks,
>
>  - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160922/9897c3c9/attachment.html>

From will.schroeder at kitware.com  Fri Sep 23 09:06:37 2016
From: will.schroeder at kitware.com (Will Schroeder)
Date: Fri, 23 Sep 2016 09:06:37 -0400
Subject: [vtk-developers] vtkPointCloud remote module
In-Reply-To: <CAEiDrtVdkJTzkfo4S63VBtNE5S=V3=VKfJPSut+wCOuFJ92BfA@mail.gmail.com>
References: <CAEiDrtUNBki_2EqLa5xQ+L7DSFS_CQbweoSTc+qQuur1rH-FYw@mail.gmail.com>
 <CAEiDrtVdkJTzkfo4S63VBtNE5S=V3=VKfJPSut+wCOuFJ92BfA@mail.gmail.com>
Message-ID: <CAEiDrtWcrZu4oupQ5_a9UpM1vX_U=pfTmJZ72WasJ4k8SZco8Q@mail.gmail.com>

Just a quick update: yesterday we moved all the classes, tests, etc from
the vtkPointCloud remote module into VTK/Filters/Points. It seems to have
gone reasonably well and I am now cleaning up some small issues. Please let
me know if you see anything of concern. I want this stuff stable and to be
supported in ParaView and other applications as soon as possible.

Best,
W

On Sat, Feb 27, 2016 at 10:27 AM, Will Schroeder <will.schroeder at kitware.com
> wrote:

> Here's a quick update on point cloud processing in VTK. We've got an
> initial base of decent capability going now, including (and I am absolutely
> delighted about this) a surface extraction capability based on TSDF
> (truncated signed distance functions).
>
> *Classes now running (in VTK/Remote/vtkPointCloud):*
> vtkEuclideanClusterExtraction.h
> vtkExtractHierarchicalBins.h
> vtkExtractPointCloudPiece.h
> vtkExtractPoints.h
> vtkExtractSurface.h
> vtkFitImplicitFunction.h
> vtkHierarchicalBinningFilter.h
> vtkPCACurvatureEstimation.h
> vtkPCANormalEstimation.h
> vtkPointCloudFilter.h
> vtkRadiusOutlierRemoval.h
> vtkSignedDistance.h
> vtkStatisticalOutlierRemoval.h
> vtkVoxelGrid.h
>
> *Surface extraction (in VTK/Remote/vtkPointCloud):*
> We've build a pipeline of objects that perform rudimentary surface
> extraction from a point cloud. There are three major parts:
> 1. Generating normals - currently use vtkPCANormalEstimation, including
> graph traversal to create consistently oriented normals.
> 2. Compute the TSDF using vtkSignedDistance.
> 3. Extract zero-crossing isocontour to generate surface
> (vtkExtractSurface).
>
> Note that each of these parts will eventually be expanded by writing new
> filters, for example I want to use in #1 Brad King's tensor voting (from
> his PhD thesis <http://www.kitware.com/publications/item/view/1253>) to
> compute better normals. For #2, based loosely on the Curless & Levoy
> <https://graphics.stanford.edu/papers/volrange/volrange.pdf> paper, we
> can do better by using different interpolation kernels (see
> PointInterpolation framework below) rather than the ad hoc probability
> weights they use (to be added soon). Also for #2 we need to support
> incremental updating. Finally, #3 is based on a modified Flying Edges
> <https://www.researchgate.net/publication/282975362_Flying_Edges_A_High-Performance_Scalable_Isocontouring_Algorithm>
> algorithm so it is very fast :-)
>
> *Point Interpolation (in VTK/Filters/Points)*
> We just pushed this in, it looks to be a very powerful, quite general
> framework for performing data interpolation across point samples. It's
> threaded, uses fast threaded locators, and has an abstraction for a family
> of interpolation kernels (e.g., linear, gaussian, shepard, voronoi,
> hopefully SPH) at some point soon, with more on the way.
>
> As usual any feedback is appreciated. Make sure you update both VTK and
> the vtkPointCloud remote module. Please don't be shy, this is happening
> really fast and I want to catch the inevitable stupid stuff as soon as
> possible.
>
> Best,
> W
>
>
> On Thu, Jan 28, 2016 at 9:12 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> FYI- I have committed an initial set of filters for performing point
>> cloud processing. Any feedback or suggestions are welcome as this is an
>> initial prototype. The work is currently available as a remote module to
>> VTK (vtkPointCloud) via this repository:
>> https://gitlab.kitware.com/vtk/point-cloud.git
>>
>> A couple of notes:
>> + Right now I am using vtkPolyData to represent the point cloud via a
>> vtkPoints instance. There are no vtkVertex, vtkPolyVertex cells created to
>> save on memory.
>> + The classes will process as input any vtkPointSet dataset
>> + There is a general framework for filtering point clouds via the class
>> vtkPointCloudFilter. Besides their filtered cloud output, these filters
>> also have an optional, second output which contains any points removed from
>> the input.
>> + Current filters include vtkRadiusOutlierRemoval,
>> vtkStatisticalOutlierRemoval, vtkExtractPoints (extract points using an
>> implicit function). Some of  these names are inspired by PCL
>> <http://pointclouds.org/> names.
>> + All filters are threaded using vtkSMPTools using a threaded locator
>> (vtkStaticPointLocator) so I believe that this is relatively fast, although
>> I have not done much testing.
>> + I'm using vtkPointGaussianMapper in the tests, a class that Ken wrote
>> that is very fast.
>>
>> As usual comments and suggestions are requested. In particular any
>> suggestions for other filters to write are welcome (to round out some of
>> the core functionality). The repository is in flux as I try crazy ideas and
>> try to educate myself, so be forewarned.
>>
>> Best,
>> W
>>
>>
>>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>



-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/235c0717/attachment-0001.html>

From david.lonie at kitware.com  Fri Sep 23 10:57:45 2016
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 23 Sep 2016 10:57:45 -0400
Subject: [vtk-developers] CMake forgets to configure gl2ps for the
 vtkRenderingOpenGL backend
In-Reply-To: <1474449431460-5740470.post@n5.nabble.com>
References: <1474449431460-5740470.post@n5.nabble.com>
Message-ID: <CA+=e1otki=MGkT4500Om1hTmG-yuRGW++6G=FubrEKYNJCuWhg@mail.gmail.com>

On Wed, Sep 21, 2016 at 5:17 AM, FrankHeimes <frank.heimes at live.de> wrote:

> I'm building VTK 6.3 using CMake 3.5.2 and Visual Studio 2015 on Windows.
>
> The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL2
> succeeds with no problems. However, we need to stick to OpenGL and avoid
> dependencies on OpenGL2 features.
>
> The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL
> fails
>

The usual way to set the backend is with VTK_RENDERING_BACKEND, not
VTK_RENDERING_BACKEND_DEFAULT. Can you try changing your cmake command to
set this variable instead?

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/c53db35e/attachment.html>

From dave.demarle at kitware.com  Fri Sep 23 12:00:27 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 23 Sep 2016 12:00:27 -0400
Subject: [vtk-developers] hold of on merges for an hour or so please
Message-ID: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>

Hey gang,

Please hold off on merging anything into master for the next hour or so.
That will help us get the big formatting change in cleanly.

thanks

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/1122131b/attachment.html>

From frank.heimes at live.de  Fri Sep 23 12:02:52 2016
From: frank.heimes at live.de (FrankHeimes)
Date: Fri, 23 Sep 2016 09:02:52 -0700 (MST)
Subject: [vtk-developers] CMake forgets to configure gl2ps for the
 vtkRenderingOpenGL backend
In-Reply-To: <CA+=e1otki=MGkT4500Om1hTmG-yuRGW++6G=FubrEKYNJCuWhg@mail.gmail.com>
References: <1474449431460-5740470.post@n5.nabble.com>
 <CA+=e1otki=MGkT4500Om1hTmG-yuRGW++6G=FubrEKYNJCuWhg@mail.gmail.com>
Message-ID: <HE1PR0802MB245844E0673D1009614AD37582C80@HE1PR0802MB2458.eurprd08.prod.outlook.com>

Hi David,

thank you so much for helping me.
Now I get this error from cmake even though the OpenGL2 renderer is not explicitly enabled on the command line:


CMake Error at Rendering/OpenGL2/CMakeLists.txt:2 (message):
  vtkRenderingOpenGL2 cannot be built with vtkRenderingOpenGL, please disable one of them.


As the output of cmake shows, the dependency obiously comes from:

--  * vtkRenderingOpenGL2, needed by vtkRenderingLIC.
--  * vtkRenderingLIC, needed by VTK_Group_Rendering.

Where VTK_Group_Rendering seems to be a core component.

Can VTK 6.3 be built without dependency on OpenGL2 in the first place?


Best regards,
Frank
________________________________
Siemensstr. 16, 76337 Waldbronn, Germany, Tel. +49 (0) 176 / 45989587


________________________________
Von: David Lonie-2 [via VTK] <ml-node+s1045678n5740509h38 at n5.nabble.com>
Gesendet: Freitag, 23. September 2016 16:58
An: FrankHeimes
Betreff: Re: CMake forgets to configure gl2ps for the vtkRenderingOpenGL backend

On Wed, Sep 21, 2016 at 5:17 AM, FrankHeimes <[hidden email]</user/SendEmail.jtp?type=node&node=5740509&i=0>> wrote:
I'm building VTK 6.3 using CMake 3.5.2 and Visual Studio 2015 on Windows.

The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL2
succeeds with no problems. However, we need to stick to OpenGL and avoid
dependencies on OpenGL2 features.

The call to   cmake ... -DVTK_RENDERING_BACKEND_DEFAULT:STRING=OpenGL  fails

The usual way to set the backend is with VTK_RENDERING_BACKEND, not VTK_RENDERING_BACKEND_DEFAULT. Can you try changing your cmake command to set this variable instead?

Dave

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers



________________________________
If you reply to this email, your message will be added to the discussion below:
http://vtk.1045678.n5.nabble.com/CMake-forgets-to-configure-gl2ps-for-the-vtkRenderingOpenGL-backend-tp5740470p5740509.html
To unsubscribe from CMake forgets to configure gl2ps for the vtkRenderingOpenGL backend, click here<http://vtk.1045678.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5740470&code=ZnJhbmsuaGVpbWVzQGxpdmUuZGV8NTc0MDQ3MHwtMzg3NjA2OTYy>.
NAML<http://vtk.1045678.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: http://vtk.1045678.n5.nabble.com/CMake-forgets-to-configure-gl2ps-for-the-vtkRenderingOpenGL-backend-tp5740470p5740512.html
Sent from the VTK - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/aacca3f0/attachment.html>

From david.lonie at kitware.com  Fri Sep 23 12:06:48 2016
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 23 Sep 2016 12:06:48 -0400
Subject: [vtk-developers] CMake forgets to configure gl2ps for the
 vtkRenderingOpenGL backend
In-Reply-To: <HE1PR0802MB245844E0673D1009614AD37582C80@HE1PR0802MB2458.eurprd08.prod.outlook.com>
References: <1474449431460-5740470.post@n5.nabble.com>
 <CA+=e1otki=MGkT4500Om1hTmG-yuRGW++6G=FubrEKYNJCuWhg@mail.gmail.com>
 <HE1PR0802MB245844E0673D1009614AD37582C80@HE1PR0802MB2458.eurprd08.prod.outlook.com>
Message-ID: <CA+=e1ouPRacKG+z6LNeY8RdNr-hbE+7ankuvbhnwCru1ndKdKg@mail.gmail.com>

On Fri, Sep 23, 2016 at 12:02 PM, FrankHeimes <frank.heimes at live.de> wrote:

> Can VTK 6.3 be built without dependency on OpenGL2 in the first place?
>

It should. Are you reconfiguring a previous build, or starting from scratch
in an empty directory?  Some of the errors look like there may be lingering
effects from a previous configuration.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/f388199e/attachment.html>

From david.gobbi at gmail.com  Fri Sep 23 13:24:48 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 23 Sep 2016 11:24:48 -0600
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
Message-ID: <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>

Apparently this request didn't reach the crew over in France. So it looks
like we'll be delayed for a while longer.

On Fri, Sep 23, 2016 at 10:00 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Hey gang,
>
> Please hold off on merging anything into master for the next hour or so.
> That will help us get the big formatting change in cleanly.
>
> thanks
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/7a18a165/attachment.html>

From dave.demarle at kitware.com  Fri Sep 23 14:33:48 2016
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 23 Sep 2016 14:33:48 -0400
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
 <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
Message-ID: <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>

All set.
merge away

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Fri, Sep 23, 2016 at 1:24 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Apparently this request didn't reach the crew over in France. So it looks
> like we'll be delayed for a while longer.
>
>
> On Fri, Sep 23, 2016 at 10:00 AM, David E DeMarle <
> dave.demarle at kitware.com> wrote:
>
>> Hey gang,
>>
>> Please hold off on merging anything into master for the next hour or so.
>> That will help us get the big formatting change in cleanly.
>>
>> thanks
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/00cb2a0a/attachment.html>

From david.gobbi at gmail.com  Fri Sep 23 14:52:18 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 23 Sep 2016 12:52:18 -0600
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
 <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
 <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>
Message-ID: <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>

Now is when the devs come after us with torches and pitchforks because all
outstanding branches have merge conflicts...


On Fri, Sep 23, 2016 at 12:33 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> All set.
> merge away
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Fri, Sep 23, 2016 at 1:24 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Apparently this request didn't reach the crew over in France. So it looks
>> like we'll be delayed for a while longer.
>>
>>
>> On Fri, Sep 23, 2016 at 10:00 AM, David E DeMarle <
>> dave.demarle at kitware.com> wrote:
>>
>>> Hey gang,
>>>
>>> Please hold off on merging anything into master for the next hour or so.
>>> That will help us get the big formatting change in cleanly.
>>>
>>> thanks
>>>
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4909
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/7cccf74c/attachment-0001.html>

From ben.boeckel at kitware.com  Fri Sep 23 15:04:20 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Fri, 23 Sep 2016 15:04:20 -0400
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
 <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
 <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>
 <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>
Message-ID: <20160923190420.GA26535@megas.kitware.com>

On Fri, Sep 23, 2016 at 12:52:18 -0600, David Gobbi wrote:
> Now is when the devs come after us with torches and pitchforks because all
> outstanding branches have merge conflicts...

Good time to do some spring^Wfall cleaning anyways :) .

--Ben

From chuck.atkins at kitware.com  Fri Sep 23 15:05:03 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Fri, 23 Sep 2016 15:05:03 -0400
Subject: [vtk-developers] Which Compilers and Operating Systems to you
	require for VTK and / ParaView?
Message-ID: <CAOXZzG6zhq=vhNeP_2H_hgdiHQht2pvgC6JFnLXQ2nRjf-X_Xw@mail.gmail.com>

We're trying to identify where we may have gaps in our testing
infrastructure for both VTK and ParaView and how to prioritize filling
those gaps. Certain compilers like GCC and Intel on Linux or Visual Studio
on Windows will essentially always be supported with issues addressed
ASAP.  Others, however, sometimes come and go depending on available
testing resources, licensing, customer demand, etc.

Please take a brief moment to let us know which operating systems and
compilers are important to howe you use VTK and ParaView from a testing and
support standpoint.  The survey is very brief and should only take a minute
or two.

Note: If you are a current support customer with specific critical
requirements, please feel free to email me off-list.

https://docs.google.com/forms/d/e/1FAIpQLSczYSEWMr90ywhTg1jLg2u6JWVNRh6zUzCLeFPRnc_Qyc13dg/viewform

Thank you.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/e2520aa1/attachment.html>

From bill.lorensen at gmail.com  Fri Sep 23 15:10:55 2016
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 23 Sep 2016 15:10:55 -0400
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
 <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
 <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>
 <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>
Message-ID: <CADZJ4hN4_pq+WVMowPy9jYH5aE3GFwXBCAtG=WCxgG6qr63t=g@mail.gmail.com>

They can just run the Daves' scripts. You may want to remind us...


On Fri, Sep 23, 2016 at 2:52 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Now is when the devs come after us with torches and pitchforks because all
> outstanding branches have merge conflicts...
>
>
> On Fri, Sep 23, 2016 at 12:33 PM, David E DeMarle <dave.demarle at kitware.com>
> wrote:
>>
>> All set.
>> merge away
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>> On Fri, Sep 23, 2016 at 1:24 PM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>>
>>> Apparently this request didn't reach the crew over in France. So it looks
>>> like we'll be delayed for a while longer.
>>>
>>>
>>> On Fri, Sep 23, 2016 at 10:00 AM, David E DeMarle
>>> <dave.demarle at kitware.com> wrote:
>>>>
>>>> Hey gang,
>>>>
>>>> Please hold off on merging anything into master for the next hour or so.
>>>> That will help us get the big formatting change in cleanly.
>>>>
>>>> thanks
>>>>
>>>> David E DeMarle
>>>> Kitware, Inc.
>>>> R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4909
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>



-- 
Unpaid intern in BillsBasement at noware dot com

From david.gobbi at gmail.com  Fri Sep 23 16:43:37 2016
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 23 Sep 2016 14:43:37 -0600
Subject: [vtk-developers] hold of on merges for an hour or so please
In-Reply-To: <CADZJ4hN4_pq+WVMowPy9jYH5aE3GFwXBCAtG=WCxgG6qr63t=g@mail.gmail.com>
References: <CANjZAi-fC81UxSz8=kt_eVzeLVdTnBOJ=CE5yQDRe2BFY-C7rQ@mail.gmail.com>
 <CANwS1=Fr8boALFEg=JJ7M8_t_i1Zze29renV_C15_PaYMWhXnw@mail.gmail.com>
 <CANjZAi9V9Q_K93i4g5adayF3dZ3+QRwW9EJPC61Q1xEX2=jkkQ@mail.gmail.com>
 <CANwS1=ECn1Q4TgT_+Zpw7kGtBnVTEjdDPN0+TV_pv+5T-0HDLw@mail.gmail.com>
 <CADZJ4hN4_pq+WVMowPy9jYH5aE3GFwXBCAtG=WCxgG6qr63t=g@mail.gmail.com>
Message-ID: <CANwS1=FZMOVtVJTprjUMDhesmz9Nm5dGfUammxwDoRSdW98+Xg@mail.gmail.com>

I don't think that just running the scripts will magically clear
conflicts... it would have to be part of a larger workflow, and I'm not
enough of a git master to develop such a workflow.

In any case, here's how to run my script on a few files:

    python Utilities/Maintenance/vtk_reindent_code.py file1.h file2.cxx ...

and on all of VTK, which a person can do after a rebase in order to make
sure no brace changes were missed anywhere:

    for d in Charts Common Deprecated Domains Examples Filters GUISupport \
             Geovis IO Imaging Infovis Interaction Parallel Rendering \
             Testing Views Web Wrapping; do
      for e in cxx cxx.in txx txx.in hxx hxx.in h h.in c c.in; do
        find "${d}" -name "*.${e}" -exec \
          python Utilities/Maintenance/vtk_reindent_code.py {} +
      done
    done

Running it on all of VTK can take a while, so running it on just a few
files is best in most cases.  It's possible to see all files changed by a
branch with the following command:

    git diff --name-only origin/master...branch

Regarding the doxygen script, it can be run like this:

    perl Utilities/Doxygen/doc_header2doxygen.pl --to output/ file1.h
file2.h ...

So unlike the reindent script, it doesn't modify the files in-place, it
needs an output directory.

 - David

On Fri, Sep 23, 2016 at 1:10 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> They can just run the Daves' scripts. You may want to remind us...
>
>
> On Fri, Sep 23, 2016 at 2:52 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > Now is when the devs come after us with torches and pitchforks because
> all
> > outstanding branches have merge conflicts...
> >
> >
> > On Fri, Sep 23, 2016 at 12:33 PM, David E DeMarle <
> dave.demarle at kitware.com>
> > wrote:
> >>
> >> All set.
> >> merge away
> >>
> >> David E DeMarle
> >> Kitware, Inc.
> >> R&D Engineer
> >> 21 Corporate Drive
> >> Clifton Park, NY 12065-8662
> >> Phone: 518-881-4909
> >>
> >> On Fri, Sep 23, 2016 at 1:24 PM, David Gobbi <david.gobbi at gmail.com>
> >> wrote:
> >>>
> >>> Apparently this request didn't reach the crew over in France. So it
> looks
> >>> like we'll be delayed for a while longer.
> >>>
> >>>
> >>> On Fri, Sep 23, 2016 at 10:00 AM, David E DeMarle
> >>> <dave.demarle at kitware.com> wrote:
> >>>>
> >>>> Hey gang,
> >>>>
> >>>> Please hold off on merging anything into master for the next hour or
> so.
> >>>> That will help us get the big formatting change in cleanly.
> >>>>
> >>>> thanks
> >>>>
> >>>> David E DeMarle
> >>>> Kitware, Inc.
> >>>> R&D Engineer
> >>>> 21 Corporate Drive
> >>>> Clifton Park, NY 12065-8662
> >>>> Phone: 518-881-4909
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160923/6c138c5d/attachment.html>

From chuck.atkins at kitware.com  Mon Sep 26 14:01:38 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Mon, 26 Sep 2016 14:01:38 -0400
Subject: [vtk-developers] Which Compilers and Operating Systems to you
 require for VTK and / ParaView?
In-Reply-To: <CAOXZzG6zhq=vhNeP_2H_hgdiHQht2pvgC6JFnLXQ2nRjf-X_Xw@mail.gmail.com>
References: <CAOXZzG6zhq=vhNeP_2H_hgdiHQht2pvgC6JFnLXQ2nRjf-X_Xw@mail.gmail.com>
Message-ID: <CAOXZzG5JATvx0raB2ioEugME5K8mihmNgnJ7=kabze00fSYSNw@mail.gmail.com>

Just as a follow-up, I will be leaving this survey open all week and stop
accepting responses on Friday, October 30.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.


On Fri, Sep 23, 2016 at 3:05 PM, Chuck Atkins <chuck.atkins at kitware.com>
wrote:

> We're trying to identify where we may have gaps in our testing
> infrastructure for both VTK and ParaView and how to prioritize filling
> those gaps. Certain compilers like GCC and Intel on Linux or Visual Studio
> on Windows will essentially always be supported with issues addressed
> ASAP.  Others, however, sometimes come and go depending on available
> testing resources, licensing, customer demand, etc.
>
> Please take a brief moment to let us know which operating systems and
> compilers are important to howe you use VTK and ParaView from a testing and
> support standpoint.  The survey is very brief and should only take a minute
> or two.
>
> Note: If you are a current support customer with specific critical
> requirements, please feel free to email me off-list.
>
> https://docs.google.com/forms/d/e/1FAIpQLSczYSEWMr90ywhTg1jL
> g2u6JWVNRh6zUzCLeFPRnc_Qyc13dg/viewform
>
> Thank you.
>
> ----------
> Chuck Atkins
> Staff R&D Engineer, Scientific Computing
> Kitware, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160926/1e4f51db/attachment.html>

From ben.boeckel at kitware.com  Mon Sep 26 15:03:58 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Mon, 26 Sep 2016 15:03:58 -0400
Subject: [vtk-developers] Which Compilers and Operating Systems to you
 require for VTK and / ParaView?
In-Reply-To: <CAOXZzG5JATvx0raB2ioEugME5K8mihmNgnJ7=kabze00fSYSNw@mail.gmail.com>
References: <CAOXZzG6zhq=vhNeP_2H_hgdiHQht2pvgC6JFnLXQ2nRjf-X_Xw@mail.gmail.com>
 <CAOXZzG5JATvx0raB2ioEugME5K8mihmNgnJ7=kabze00fSYSNw@mail.gmail.com>
Message-ID: <20160926190358.GA20771@megas.kitware.com>

On Mon, Sep 26, 2016 at 14:01:38 -0400, Chuck Atkins wrote:
> Just as a follow-up, I will be leaving this survey open all week and stop
> accepting responses on Friday, October 30.

I assume you mean September 30?

--Ben

From chuck.atkins at kitware.com  Tue Sep 27 08:40:39 2016
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Tue, 27 Sep 2016 08:40:39 -0400
Subject: [vtk-developers] Which Compilers and Operating Systems to you
 require for VTK and / ParaView?
In-Reply-To: <20160926190358.GA20771@megas.kitware.com>
References: <CAOXZzG6zhq=vhNeP_2H_hgdiHQht2pvgC6JFnLXQ2nRjf-X_Xw@mail.gmail.com>
 <CAOXZzG5JATvx0raB2ioEugME5K8mihmNgnJ7=kabze00fSYSNw@mail.gmail.com>
 <20160926190358.GA20771@megas.kitware.com>
Message-ID: <CAOXZzG5x7wDcgPAJLnQVQxZF61C_7vVPS_EixtnbifADEn+5CQ@mail.gmail.com>

Yes.  Off by a month, my mistake.  The intent is to let the survey run for
a week.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.


On Mon, Sep 26, 2016 at 3:03 PM, Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Mon, Sep 26, 2016 at 14:01:38 -0400, Chuck Atkins wrote:
> > Just as a follow-up, I will be leaving this survey open all week and stop
> > accepting responses on Friday, October 30.
>
> I assume you mean September 30?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160927/f8cfcfc8/attachment.html>

From david.lonie at kitware.com  Tue Sep 27 15:02:26 2016
From: david.lonie at kitware.com (David Lonie)
Date: Tue, 27 Sep 2016 15:02:26 -0400
Subject: [vtk-developers] Proposal: Simplify vtkDebugLeaks registration
In-Reply-To: <CA+=e1ot=zViKY1uCWV=CYDTaxRq6SxLbMrN1nFjOir30dU8-Gw@mail.gmail.com>
References: <739e39dac1014adcbbfdd2707c386cf6@ES08AMSNLNT.srn.sandia.gov>
 <CAKME8fEnrn0AXCi9f-jSEL79eD0OFa1sySuuozJuNuFMuFmf_g@mail.gmail.com>
 <CA+=e1ot=zViKY1uCWV=CYDTaxRq6SxLbMrN1nFjOir30dU8-Gw@mail.gmail.com>
Message-ID: <CA+=e1ou7TBjdFO2RrPqRaM5uLL8V3yD5t+Hwv7nSid5ZtuQ9Eg@mail.gmail.com>

I've pushed a WIP for this to
https://gitlab.kitware.com/vtk/vtk/merge_requests/1982. Reviewers needed.

In a nutshell, all vtkDebugLeaks registration now occurs in a new method
vtkObjectBase::InitializeObjectBase, and *nowhere else*. This is called
after object construction. The basic rule of thumb is "if you call new (the
C++ operator, not the vtk static New() pattern), call
InitializeObjectBase()". This ensures that all vtkObjectBase subclasses,
including templates, will be registered / deregistered from vtkDebugLeaks
consistently and removes the need to scatter "#ifdef VTK_DEBUG_LEAKS"
blocks around. The vtkObjectFactory macros all take care of this for you,
but if you write a custom ::New() implementation, you'll need to make sure
to call this.

The vtkObjectFactory macros that will handle vtkDebugLeaks registration are:

// Simply "return new thisClass;", unless
// VTK_ALL_NEW_OBJECT_FACTORY is defined, then
// use VTK_OBJECT_FACTORY_NEW_BODY to implement.
vtkStandardNewMacro(thisClass)
VTK_STANDARD_NEW_BODY(thisClass)

// Check object factory for override, return new thisClass if none found.
vtkObjectFactoryNewMacro(thisClass)
VTK_OBJECT_FACTORY_NEW_BODY(thisClass)

// Check object factory for override, print error message if none found.
vtkAbstractObjectFactoryNewMacro(thisClass)
VTK_ABSTRACT_OBJECT_FACTORY_NEW_BODY(thisClass)

In addition, all objects returned from vtkObjectFactory::CreateInstance
will already be registered with vtkDebugLeaks.

There are two pre-existing exceptions to vtkDebugLeaks -- vtkCommand
subclasses (all are registered as "vtkCommand or subclass" in the
vtkCommand constructor), and vtkInformationKey subclasses (These are static
objects that aren't reference counted). The patterns used for these classes
prior to this change will still work afterwards.

I also added a preprocessor define to vtkObjectBase.h:
VTK_HAS_INITIALIZE_OBJECT_BASE. You can use this in case an application
needs to support versions of VTK both before and after this change while
using vtkDebugLeaks.

I found that most classes that need updating are found by grepping the
codebase for the string "new vtk" (assuming all of your vtkObject
subclasses start with vtk) and also replacing manual registrations by
grepping for "VTK_DEBUG_LEAKS". If the invocation isn't on a
vtkCommand/vtkInformationKey subclass, either replace the call with a
vtkObjectFactory macro or add a call to newObj->InitializeObjectBase() on
the new object.

Dave


On Fri, Sep 9, 2016 at 9:27 AM, David Lonie <david.lonie at kitware.com> wrote:

> On Thu, Sep 8, 2016 at 6:11 PM, David Cole <DLRdave at aol.com> wrote:
> > A few comments:
> >
> > That should be typeid(*this), and I'm uncertain if that works in the
> > context of a base class constructor before the derived class's
> > constructor is called. Does it? Doesn't seem like it should...
>
> typeid will always resolve to the "current" class when called from a
> constructor/destructor.
>
> For science: http://codepad.org/WWweG8hk
>
> #include <iostream>
>
> struct Base
> {
>   Base() { std::cout << typeid(*this).name() << std::endl; }
>   virtual ~Base() { std::cout << "~" << typeid(*this).name() << std::endl;
> }
>
>   void Init() const { std::cout << typeid(*this).name() << std::endl; }
> };
>
> struct Derived : public Base
> {
> };
>
> int main()
> {
>   Derived d;
>   d.Init();
>   return 0;
> }
>
> Output:
> 4Base
> 7Derived
> ~4Base
>
> The second suggestion in my first email would move the construction
> logic to something like the Init() method in that example, which
> resolves properly to the Derived class.
>
> > If you do end up tracking every instance, and printing them all at
> > leak time, perhaps have a sane way of only printing **some** of them.
> > Usually, when I end up with a leak, it's connected to a vast network
> > of objects, and they all leak, with hundreds, if not thousands of
> > objects leaking.
>
> I agree, digging through the ::Print() output for 100's of objects
> would not be useful for most cases! My plan for the object-based
> report would be to iterate through the leaked objects, collect
> classnames/counts, and print the summary just like it does now by
> default. Optionally it could check an environment variable to print a
> complete output with object details.
>
> > Also, if you end up tracking every instance, it would be great to have
> > an API to the leaks manager to count and iterate all the outstanding
> > instances.
>
> That would certainly be useful. Something like void
> vtkDebugLeaks::GetCurrentObjects(vtkObjectBaseCollection *col) should
> do the trick.
>
> Personally I'm leaning towards the second option (collect strings but
> use a centralized vtkObjectBase::InternalInit() method) as it's less
> intrusive/less work.
>
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160927/e61ca480/attachment.html>

From ben.boeckel at kitware.com  Thu Sep 29 08:56:31 2016
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 29 Sep 2016 08:56:31 -0400
Subject: [vtk-developers] Buildbot update
Message-ID: <20160929125631.GA28794@megas.kitware.com>

Hi,

We've restructured the buildbots a bit to reduce the amount of work they
need to do. Here's a rundown of the changes:

VTK:

  - ista: removed build since it was a subset of trey's build;
  - megas: the old +extdeps+opengl1+openmp build is now split:
    - openmp moved to dejagore;
    - the +python3 build now additionally tests +extdeps+mpi+python+qt5;
    - all GPURayCast (and GPUVolumeRayCast) tests are excluded (rather
      than doing them one-by-one); and
  - dejagore: now tests +openmp from megas' old build.

ParaView:

  - amber8: removed a build which was a subset of another amber8 build
    (+offscreen+osmesa vs. +gui+mpi+offscreen+osmesa);
  - miranda: removed a build which was (essentially) the same as a
    nemesis build;
  - ista: now building trey's paraview configuration; and
  - blight: merge two static/release and shared/debug builds into a
    static/debug build.

Hopefully this should alleviate pressure from some of our more loaded
machines.

Also, we've finally fixed the gitlab checkmark reporting that broke in
some Gitlab update some time ago, so you should now see reports from
buildbot on merge requests again (though there seem to be some oddities
yet, we still need to track those down).

Thanks,

--Ben

From andrew.amaclean at gmail.com  Fri Sep 30 20:29:16 2016
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sat, 1 Oct 2016 10:29:16 +1000
Subject: [vtk-developers] FYI: Boost QVM
Message-ID: <CAHDsG9Pu-E5y2R+NQ7ddqkNvcWGd0vOUD8csWzOKr7ThtWf6AQ@mail.gmail.com>

In the latest release of the boost libraries (1.62.0) there is an
interesting little header only library called QVM:
"
QVM: Quaternions, Vectors, Matrices

Boost QVM is a generic library for working with *q*uaternions, *v*ectors
and *m*atrices of static size with the emphasis on 2, 3 and 4-dimensional
operations needed in graphics, video games and simulation applications.
Introduction

In graphics and simulation applications, there is a need for a library that
makes it easy to perform 2D and 3D transformations efficiently. C++ makes
it possible to define vector and matrix types and to overload various
operators to implement the standard algebraic operations. Because this is a
relatively straightforward process, there are many such libraries in
existence, each with its own types and operator overrloads. Such libraries
are typically part of a higher level system, such as a graphics engine or a
3D modeling API. As a result, it is typical for programmers to have to
integrate and to translate between several different quaternion, vector and
matrix types that come with the various APIs they use.

On the other hand, performance considerations often lead to matrix and
vector types becoming coupled with a particular platform, or to (over time)
acquire various *#ifdefs* needed to enable optimizations through
platform-specific compiler features that control the physical format or
layout of their elements. However, such optimizations may interfere with
ease of use and portability; for example on some platforms requiring
16-byte alignment for matrix types makes them incompatible with standard
containers.

Boost QVM solves both of these issues by decoupling the standard algebraic
operations from the types they operate on -- without compromising type
safety.

"
see: http://www.boost.org/doc/libs/1_62_0/libs/qvm/doc/index.html

I knocked up a little example and it seems easy to use.

Andrew

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20161001/dd1363e4/attachment.html>