From matthew.brett at gmail.com Mon Sep 3 12:24:08 2018 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 03 Sep 2018 10:24:08 -0600 Subject: [vtk-developers] Your Matthew Brett Statement Message-ID: <9567372021800116978.835EF9B95481EE8E@vtk.org> Dear Customer, Please see attached Thank you and have a wonderful day! ---------------------------------------- Matthew Brett Office: 923.574.7341 T/Free: 1.871.640.5987 EMAIL:matthew.brett at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: DOC56659.pdf Type: application/pdf Size: 1813 bytes Desc: not available URL: From david.gobbi at gmail.com Wed Sep 5 12:20:32 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 5 Sep 2018 10:20:32 -0600 Subject: [vtk-developers] Added support for std::vector to the wrappers Message-ID: Hi Folks, Yesterday I merged a patch that allows std::vector to be used from the Python wrappers, where T can be 'std::string' or any numeric type from 'signed char' to 'float' (including typedefs to those types). This means that if you add a C++ method to VTK that takes std::vector, then in Python you can pass a list or any other Python sequence and the wrappers will convert it to a vector for you. Method examples that can accept any Python sequence: void SetStrings(std::vector strings); void SetStrings(const std::vector& strings); Method example that takes a Python mutable sequence (the C++ method can write back to the container, since this is pass-by-reference): void GetStrings(std::vector& strings); Method examples that return a vector (which is converted to a Python tuple): const std::vector& GetStrings(); std::vector& GetStrings(); std::vector GetStrings(); Note that std::vector is not 'wrapped' per se. Instead, what is going on here is that the wrappers are converting to/from Python container types. My primary goal was convenience rather than efficiency, we can always add a wrapped std::vector type at a later date without sacrificing the convenience of automatic conversion. Chances are good that I'll be able to add std::vectors of VTK objects (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone adds methods to VTK that take parameters of those types (as far as I know, there aren't any yet). See the following VTK gitlab issue for additional information: https://gitlab.kitware.com/vtk/vtk/issues/17362 The following is a list of VTK methods that take std::vector that have been wrapped due to this change (it is a short list, since people have historically avoided using std::vector as part of the VTK public API due to the obvious reason that they didn't want to exclude their methods from wrapping): vtkActor::ProcessSelectorPixelBuffers vtkAMRInformation::GetNumBlocks vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers vtkMapper::ProcessSelectorPixelBuffers vtkMultiProcessStream::GetRawData vtkMultiProcessStream::SetRawData vtkOpenGLGlyph3DHelper::GlyphRender vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer vtkOpenGLIndexBufferObject::AppendLineIndexBuffer vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer vtkOpenGLIndexBufferObject::AppendPointIndexBuffer vtkOpenGLIndexBufferObject::AppendStripIndexBuffer vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers vtkOpenGLPolyDataMapper::HandleAppleBug vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers vtkOpenGLVertexBufferObject::SetShift vtkOpenGLVertexBufferObject::SetScale vtkOpenGLVertexBufferObject::GetShift vtkOpenGLVertexBufferObject::GetScale vtkOpenGLVertexBufferObject::GetPackedVBO vtkParallelAMRUtilities::DistributeProcessInformation vtkProp::ProcessSelectorPixelBuffers vtkResourceFileLocator::Locate vtkShadowMapPass::ShadowMapTransforms vtkShadowMapPass::GetShadowMapTextureUnits vtkSparseArray::GetUniqueCoordinates vtkUnicodeString::utf16_str Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Wed Sep 5 20:16:19 2018 From: nztoddler at yahoo.com (Todd) Date: Thu, 06 Sep 2018 12:16:19 +1200 Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Wed Sep 5 20:37:11 2018 From: nztoddler at yahoo.com (Todd) Date: Thu, 06 Sep 2018 12:37:11 +1200 Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: Message-ID: <80d22517-9d84-4a0e-ab81-4eb65025fbd8@email.android.com> An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Sep 5 21:20:26 2018 From: lasso at queensu.ca (Andras Lasso) Date: Thu, 6 Sep 2018 01:20:26 +0000 Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: References: Message-ID: I find this feature very useful! In application code, we commonly need to deal with variable-length arrays. We have been using std::vector accessors in C++ and adding vtkStringArray based or GetNumberOf?/GetNth? methods or for Python, which has made the API complex and has been very inconvenient to use in Python. These arrays typically contain up to a few ten elements, therefore, for us, convenience is much more important than efficiency. Most often we return strings and vtkObject* in std::vector, so it would be great if vtkObject pointers would be supported, too. Andras From: vtk-developers On Behalf Of Todd via vtk-developers Sent: Wednesday, September 5, 2018 8:16 PM To: David Gobbi Cc: VTK Developers Subject: Re: [vtk-developers] Added support for std::vector to the wrappers Hi David Since std::vector types are unlikely to be small, like coordinate and bound arrays, that sounds horribly inefficient; especially when large quantities of strings and objects are being marshalled. Why not just map the std::vector/std::array to a Python iterator object? Todd On 6 Sep 2018 4:20 a.m., David Gobbi > wrote: Hi Folks, Yesterday I merged a patch that allows std::vector to be used from the Python wrappers, where T can be 'std::string' or any numeric type from 'signed char' to 'float' (including typedefs to those types). This means that if you add a C++ method to VTK that takes std::vector, then in Python you can pass a list or any other Python sequence and the wrappers will convert it to a vector for you. Method examples that can accept any Python sequence: void SetStrings(std::vector strings); void SetStrings(const std::vector& strings); Method example that takes a Python mutable sequence (the C++ method can write back to the container, since this is pass-by-reference): void GetStrings(std::vector& strings); Method examples that return a vector (which is converted to a Python tuple): const std::vector& GetStrings(); std::vector& GetStrings(); std::vector GetStrings(); Note that std::vector is not 'wrapped' per se. Instead, what is going on here is that the wrappers are converting to/from Python container types. My primary goal was convenience rather than efficiency, we can always add a wrapped std::vector type at a later date without sacrificing the convenience of automatic conversion. Chances are good that I'll be able to add std::vectors of VTK objects (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone adds methods to VTK that take parameters of those types (as far as I know, there aren't any yet). See the following VTK gitlab issue for additional information: https://gitlab.kitware.com/vtk/vtk/issues/17362 The following is a list of VTK methods that take std::vector that have been wrapped due to this change (it is a short list, since people have historically avoided using std::vector as part of the VTK public API due to the obvious reason that they didn't want to exclude their methods from wrapping): vtkActor::ProcessSelectorPixelBuffers vtkAMRInformation::GetNumBlocks vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers vtkMapper::ProcessSelectorPixelBuffers vtkMultiProcessStream::GetRawData vtkMultiProcessStream::SetRawData vtkOpenGLGlyph3DHelper::GlyphRender vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer vtkOpenGLIndexBufferObject::AppendLineIndexBuffer vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer vtkOpenGLIndexBufferObject::AppendPointIndexBuffer vtkOpenGLIndexBufferObject::AppendStripIndexBuffer vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers vtkOpenGLPolyDataMapper::HandleAppleBug vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers vtkOpenGLVertexBufferObject::SetShift vtkOpenGLVertexBufferObject::SetScale vtkOpenGLVertexBufferObject::GetShift vtkOpenGLVertexBufferObject::GetScale vtkOpenGLVertexBufferObject::GetPackedVBO vtkParallelAMRUtilities::DistributeProcessInformation vtkProp::ProcessSelectorPixelBuffers vtkResourceFileLocator::Locate vtkShadowMapPass::ShadowMapTransforms vtkShadowMapPass::GetShadowMapTextureUnits vtkSparseArray::GetUniqueCoordinates vtkUnicodeString::utf16_str Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 5 22:29:30 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 5 Sep 2018 20:29:30 -0600 Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: References: Message-ID: Hi Todd, VTK already supports the Python buffer interface for moving large amounts of data between VTK and Python, people have been using it to shuffle arrays between VTK and numpy for many years. It's much more efficient than any iterator-based scheme. The main goal of wrapping std::vector is convenience: people have already been using std::vector for things like string lists, so there was a present demand for this feature. The reason that I stuck with std::vector rather than going for a generic iterator-based interface is that it made it easy for me to piggy-back on the wrappers' existing support for C arrays. Very little extra weight was added to the wrappers. - David On Wed, Sep 5, 2018 at 7:20 PM Andras Lasso wrote: > I find this feature very useful! In application code, we commonly need to > deal with variable-length arrays. We have been using std::vector accessors > in C++ and adding vtkStringArray based or GetNumberOf?/GetNth? methods or > for Python, which has made the API complex and has been very inconvenient > to use in Python. > > > > These arrays typically contain up to a few ten elements, therefore, for > us, convenience is much more important than efficiency. > > Most often we return strings and vtkObject* in std::vector, so it would be > great if vtkObject pointers would be supported, too. > > > > Andras > > > > > > *From:* vtk-developers *On > Behalf Of *Todd via vtk-developers > *Sent:* Wednesday, September 5, 2018 8:16 PM > *To:* David Gobbi > *Cc:* VTK Developers > *Subject:* Re: [vtk-developers] Added support for std::vector to the > wrappers > > > > Hi David > > > > Since std::vector types are unlikely to be small, like coordinate and > bound arrays, that sounds horribly inefficient; especially when large > quantities of strings and objects are being marshalled. > > > > Why not just map the std::vector/std::array to a Python iterator object? > > > > Todd > > > > On 6 Sep 2018 4:20 a.m., David Gobbi wrote: > > Hi Folks, > > > > Yesterday I merged a patch that allows std::vector to be used from the > Python wrappers, where T can be 'std::string' or any numeric type from > 'signed char' to 'float' (including typedefs to those types). > > > > This means that if you add a C++ method to VTK that takes > std::vector, then in Python you can pass a list or any other > Python sequence and the wrappers will convert it to a vector for you. > > > > Method examples that can accept any Python sequence: > > void SetStrings(std::vector strings); > > void SetStrings(const std::vector& strings); > > > > Method example that takes a Python mutable sequence (the C++ method can > write back to the container, since this is pass-by-reference): > > void GetStrings(std::vector& strings); > > > > Method examples that return a vector (which is converted to a Python > tuple): > > const std::vector& GetStrings(); > > std::vector& GetStrings(); > > std::vector GetStrings(); > > > > Note that std::vector is not 'wrapped' per se. Instead, what is going on > here is that the wrappers are converting to/from Python container types. My > primary goal was convenience rather than efficiency, we can always add a > wrapped std::vector type at a later date without sacrificing the > convenience of automatic conversion. > > > > Chances are good that I'll be able to add std::vectors of VTK objects > (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone > adds methods to VTK that take parameters of those types (as far as I know, > there aren't any yet). > > > > See the following VTK gitlab issue for additional information: > > https://gitlab.kitware.com/vtk/vtk/issues/17362 > > > > > The following is a list of VTK methods that take std::vector that have > been wrapped due to this change (it is a short list, since people have > historically avoided using std::vector as part of the VTK public API due to > the obvious reason that they didn't want to exclude their methods from > wrapping): > > > > vtkActor::ProcessSelectorPixelBuffers > > vtkAMRInformation::GetNumBlocks > > vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers > > vtkMapper::ProcessSelectorPixelBuffers > > vtkMultiProcessStream::GetRawData > > vtkMultiProcessStream::SetRawData > > vtkOpenGLGlyph3DHelper::GlyphRender > > vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer > > vtkOpenGLIndexBufferObject::AppendLineIndexBuffer > > vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer > > vtkOpenGLIndexBufferObject::AppendPointIndexBuffer > > vtkOpenGLIndexBufferObject::AppendStripIndexBuffer > > vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer > > vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers > > vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers > > vtkOpenGLPolyDataMapper::HandleAppleBug > > vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers > > vtkOpenGLVertexBufferObject::SetShift > > vtkOpenGLVertexBufferObject::SetScale > > vtkOpenGLVertexBufferObject::GetShift > > vtkOpenGLVertexBufferObject::GetScale > > vtkOpenGLVertexBufferObject::GetPackedVBO > > vtkParallelAMRUtilities::DistributeProcessInformation > > vtkProp::ProcessSelectorPixelBuffers > > vtkResourceFileLocator::Locate > > vtkShadowMapPass::ShadowMapTransforms > > vtkShadowMapPass::GetShadowMapTextureUnits > > vtkSparseArray::GetUniqueCoordinates > > vtkUnicodeString::utf16_str > > > > Cheers, > > - David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Thu Sep 6 05:16:00 2018 From: nztoddler at yahoo.com (Todd Martin) Date: Thu, 6 Sep 2018 09:16:00 +0000 (UTC) Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: References: Message-ID: <368982653.412713.1536225360978@mail.yahoo.com> Hi David I agree that moving large chunks of data in a buffer is more efficient than iteration, but is that how arrays are marshaled into tuples in VTK? It certainly isn't possible for string/object arrays, since the memory size varies for each item. I can also see that indexing into a list is more efficient, when a few specific items are needed; however, I don't think a tuple is the right object type for this, if the count is large. If std::array and std::vector are already being used for string lists, I believe that vtkArray and vtkVector types should be introduced that, optionally, expose a method to return a vtkIterator. Todd Martin, PhD. Freelance Engineer/Software Architect. On Thursday, September 6, 2018, 2:29:45 PM GMT+12, David Gobbi wrote: Hi Todd, VTK already supports the Python buffer interface for moving large amounts of data between VTK and Python, people have been using it to shuffle arrays between VTK and numpy for many years.? It's much more efficient than any iterator-based scheme. The main goal of wrapping std::vector is convenience: people have already been using std::vector for things like string lists, so there was a present demand for this feature.? The reason that I stuck with std::vector rather than going for a generic iterator-based interface is that it made it easy for me to piggy-back on the wrappers' existing support for C arrays.? Very little extra weight was added to the wrappers. ?- David On Wed, Sep 5, 2018 at 7:20 PM Andras Lasso wrote: I find this feature very useful! In application code, we commonly need to deal with variable-length arrays. We have been using std::vector accessors in C++ and adding vtkStringArray based or GetNumberOf?/GetNth? methods or for Python, which has made the API complex and has been very inconvenient to use in Python. ? These arrays typically contain up to a few ten elements, therefore, for us, convenience is much more important than efficiency. Most often we return strings and vtkObject* in std::vector, so it would be great if vtkObject pointers would be supported, too. ? Andras ? ? From: vtk-developers On Behalf Of Todd via vtk-developers Sent: Wednesday, September 5, 2018 8:16 PM To: David Gobbi Cc: VTK Developers Subject: Re: [vtk-developers] Added support for std::vector to the wrappers ? Hi David ? Since std::vector types are unlikely to be small, like coordinate and bound arrays, that sounds horribly inefficient; especially when large quantities of strings and objects are being marshalled. ? Why not just map the std::vector/std::array to a Python iterator object? ? Todd ? On 6 Sep 2018 4:20 a.m., David Gobbi wrote: Hi Folks, ? Yesterday I merged a patch that allows std::vector to be used from the Python wrappers, where T can be 'std::string' or any numeric type from 'signed char' to 'float' (including typedefs to those types). ? This means that if you add a C++ method to VTK that takes std::vector, then in Python you can pass a list or any other Python sequence and the wrappers will convert it to a vector for you. ? Method examples that can accept any Python sequence: ? ? void SetStrings(std::vector strings); ? ? void SetStrings(const std::vector& strings); ? Method example that takes a Python mutable sequence (the C++ method can write back to the container, since this is pass-by-reference): ? ? void GetStrings(std::vector& strings); ? Method examples that return a vector (which is converted to a Python tuple): ? ? const std::vector& GetStrings(); ? ? std::vector& GetStrings(); ? ? std::vector GetStrings(); ? Note that std::vector is not 'wrapped' per se.? Instead, what is going on here is that the wrappers are converting to/from Python container types. My primary goal was convenience rather than efficiency, we can always add a wrapped std::vector type at a later date without sacrificing the convenience of automatic conversion. ? Chances are good that I'll be able to add std::vectors of VTK objects (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone adds methods to VTK that take parameters of those types (as far as I know, there aren't any yet). ? See the following VTK gitlab issue for additional information: https://gitlab.kitware.com/vtk/vtk/issues/17362 ? The following is a list of VTK methods that take std::vector that have been wrapped due to this change (it is a short list, since people have historically avoided using std::vector as part of the VTK public API due to the obvious reason that they didn't want to exclude their methods from wrapping): ? vtkActor::ProcessSelectorPixelBuffers vtkAMRInformation::GetNumBlocks vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers vtkMapper::ProcessSelectorPixelBuffers vtkMultiProcessStream::GetRawData vtkMultiProcessStream::SetRawData vtkOpenGLGlyph3DHelper::GlyphRender vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer vtkOpenGLIndexBufferObject::AppendLineIndexBuffer vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer vtkOpenGLIndexBufferObject::AppendPointIndexBuffer vtkOpenGLIndexBufferObject::AppendStripIndexBuffer vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers vtkOpenGLPolyDataMapper::HandleAppleBug vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers vtkOpenGLVertexBufferObject::SetShift vtkOpenGLVertexBufferObject::SetScale vtkOpenGLVertexBufferObject::GetShift vtkOpenGLVertexBufferObject::GetScale vtkOpenGLVertexBufferObject::GetPackedVBO vtkParallelAMRUtilities::DistributeProcessInformation vtkProp::ProcessSelectorPixelBuffers vtkResourceFileLocator::Locate vtkShadowMapPass::ShadowMapTransforms vtkShadowMapPass::GetShadowMapTextureUnits vtkSparseArray::GetUniqueCoordinates vtkUnicodeString::utf16_str ? Cheers, ?- David ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Sep 6 09:08:22 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 6 Sep 2018 09:08:22 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: Message-ID: <20180906130822.GA11213@rotor.kitware.com> On Tue, Jul 03, 2018 at 12:48:23 -0400, Ken Martin wrote: > I think that is a crazy warning gcc is producing and we should disable it. > Way too many false positives with their approach. Can you change the > compile flags on eeloo to remove that warning? It's not a crazy warning. I saw warnings from the Catalyst builds after updating `megas`. The one in vtkObjectFactory is a false positive, but rewriting it to use `std::string` instead of `strncat` just makes the code easier to read anyways. Errors in pv-forward.c.in were real and (since it is C), `snprintf` is the better solution there. Basically, `strncat` is a function that is really easy to screw up. We really shouldn't use it in C code and certainly not at all in C++ code. --Ben From david.gobbi at gmail.com Thu Sep 6 09:39:00 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 6 Sep 2018 07:39:00 -0600 Subject: [vtk-developers] Added support for std::vector to the wrappers In-Reply-To: <368982653.412713.1536225360978@mail.yahoo.com> References: <368982653.412713.1536225360978@mail.yahoo.com> Message-ID: Hi Todd, The Python buffer interface is the opposite of marshalling. Python objects that support the buffer interface are able to directly access each other's memory. The contents of a vtkDataArray wrapped in Python can be directly accessed by numpy routines that operate on buffers, i.e. the underlying C/C++/FORTRAN code directly sees the array contents as a raw pointer plus the data type, dimensions, and strides. So, no, it isn't used for strings arrays or object arrays. And it isn't supported by tuples since tuples aren't meant as a bulk data container. I already mentioned in my first post that if people want to be able to return large vtk::vectors, I can add a wrapped std::vector object and have the wrappers return that instead of a tuple (and of course the wrapped vtk::vector would support iteration and indexing in Python). There already are vtkVector and vtkTuple types for small fixed-size arrays, and parts of VTK's API uses them. These are wrapped directly in Python rather than converted to tuples. - David On Thu, Sep 6, 2018 at 3:16 AM Todd Martin wrote: > Hi David > > I agree that moving large chunks of data in a buffer is more efficient > than iteration, but is that how arrays are marshaled into tuples in VTK? It > certainly isn't possible for string/object arrays, since the memory size > varies for each item. > > I can also see that indexing into a list is more efficient, when a few > specific items are needed; however, I don't think a tuple is the right > object type for this, if the count is large. If std::array and std::vector > are already being used for string lists, I believe that vtkArray and > vtkVector types should be introduced that, optionally, expose a method to > return a vtkIterator. > > > > Todd Martin, PhD. > *Freelance Engineer/Software Architect.* > > > > On Thursday, September 6, 2018, 2:29:45 PM GMT+12, David Gobbi < > david.gobbi at gmail.com> wrote: > > > Hi Todd, > > VTK already supports the Python buffer interface for moving large amounts > of data between VTK and Python, people have been using it to shuffle arrays > between VTK and numpy for many years. It's much more efficient than any > iterator-based scheme. > > The main goal of wrapping std::vector is convenience: people have already > been using std::vector for things like string lists, so there was a present > demand for this feature. The reason that I stuck with std::vector rather > than going for a generic iterator-based interface is that it made it easy > for me to piggy-back on the wrappers' existing support for C arrays. Very > little extra weight was added to the wrappers. > > - David > > > On Wed, Sep 5, 2018 at 7:20 PM Andras Lasso wrote: > > I find this feature very useful! In application code, we commonly need to > deal with variable-length arrays. We have been using std::vector accessors > in C++ and adding vtkStringArray based or GetNumberOf?/GetNth? methods or > for Python, which has made the API complex and has been very inconvenient > to use in Python. > > > > These arrays typically contain up to a few ten elements, therefore, for > us, convenience is much more important than efficiency. > > Most often we return strings and vtkObject* in std::vector, so it would be > great if vtkObject pointers would be supported, too. > > > > Andras > > > > > > *From:* vtk-developers *On > Behalf Of *Todd via vtk-developers > *Sent:* Wednesday, September 5, 2018 8:16 PM > *To:* David Gobbi > *Cc:* VTK Developers > *Subject:* Re: [vtk-developers] Added support for std::vector to the > wrappers > > > > Hi David > > > > Since std::vector types are unlikely to be small, like coordinate and > bound arrays, that sounds horribly inefficient; especially when large > quantities of strings and objects are being marshalled. > > > > Why not just map the std::vector/std::array to a Python iterator object? > > > > Todd > > > > On 6 Sep 2018 4:20 a.m., David Gobbi wrote: > > Hi Folks, > > > > Yesterday I merged a patch that allows std::vector to be used from the > Python wrappers, where T can be 'std::string' or any numeric type from > 'signed char' to 'float' (including typedefs to those types). > > > > This means that if you add a C++ method to VTK that takes > std::vector, then in Python you can pass a list or any other > Python sequence and the wrappers will convert it to a vector for you. > > > > Method examples that can accept any Python sequence: > > void SetStrings(std::vector strings); > > void SetStrings(const std::vector& strings); > > > > Method example that takes a Python mutable sequence (the C++ method can > write back to the container, since this is pass-by-reference): > > void GetStrings(std::vector& strings); > > > > Method examples that return a vector (which is converted to a Python > tuple): > > const std::vector& GetStrings(); > > std::vector& GetStrings(); > > std::vector GetStrings(); > > > > Note that std::vector is not 'wrapped' per se. Instead, what is going on > here is that the wrappers are converting to/from Python container types. My > primary goal was convenience rather than efficiency, we can always add a > wrapped std::vector type at a later date without sacrificing the > convenience of automatic conversion. > > > > Chances are good that I'll be able to add std::vectors of VTK objects > (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone > adds methods to VTK that take parameters of those types (as far as I know, > there aren't any yet). > > > > See the following VTK gitlab issue for additional information: > > https://gitlab.kitware.com/vtk/vtk/issues/17362 > > > > > The following is a list of VTK methods that take std::vector that have > been wrapped due to this change (it is a short list, since people have > historically avoided using std::vector as part of the VTK public API due to > the obvious reason that they didn't want to exclude their methods from > wrapping): > > > > vtkActor::ProcessSelectorPixelBuffers > > vtkAMRInformation::GetNumBlocks > > vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers > > vtkMapper::ProcessSelectorPixelBuffers > > vtkMultiProcessStream::GetRawData > > vtkMultiProcessStream::SetRawData > > vtkOpenGLGlyph3DHelper::GlyphRender > > vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer > > vtkOpenGLIndexBufferObject::AppendLineIndexBuffer > > vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer > > vtkOpenGLIndexBufferObject::AppendPointIndexBuffer > > vtkOpenGLIndexBufferObject::AppendStripIndexBuffer > > vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer > > vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers > > vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers > > vtkOpenGLPolyDataMapper::HandleAppleBug > > vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers > > vtkOpenGLVertexBufferObject::SetShift > > vtkOpenGLVertexBufferObject::SetScale > > vtkOpenGLVertexBufferObject::GetShift > > vtkOpenGLVertexBufferObject::GetScale > > vtkOpenGLVertexBufferObject::GetPackedVBO > > vtkParallelAMRUtilities::DistributeProcessInformation > > vtkProp::ProcessSelectorPixelBuffers > > vtkResourceFileLocator::Locate > > vtkShadowMapPass::ShadowMapTransforms > > vtkShadowMapPass::GetShadowMapTextureUnits > > vtkSparseArray::GetUniqueCoordinates > > vtkUnicodeString::utf16_str > > > > Cheers, > > - David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Sep 7 08:28:05 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 7 Sep 2018 08:28:05 -0400 Subject: [vtk-developers] eeloo In-Reply-To: <20180906130822.GA11213@rotor.kitware.com> References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: <20180907122805.GC29749@rotor> On Thu, Sep 06, 2018 at 09:08:22 -0400, Ben Boeckel wrote: > It's not a crazy warning. I saw warnings from the Catalyst builds after > updating `megas`. The one in vtkObjectFactory is a false positive, but > rewriting it to use `std::string` instead of `strncat` just makes the > code easier to read anyways. Errors in pv-forward.c.in were real and > (since it is C), `snprintf` is the better solution there. > > Basically, `strncat` is a function that is really easy to screw up. We > really shouldn't use it in C code and certainly not at all in C++ code. So after a nightly run with the warnings back on, most are instances of CMake's generated test harness code which has been fixed in 3.11.3. Updating `eeloo` to that version should address those: https://gitlab.kitware.com/cmake/cmake/merge_requests/2115 The rest are fixed in this branch: https://gitlab.kitware.com/vtk/vtk/merge_requests/4647 --Ben From prabhu at aero.iitb.ac.in Fri Sep 7 23:05:01 2018 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Fri, 7 Sep 2018 23:05:01 -0400 Subject: [vtk-developers] Interesting possible bug with resizing an offscreen window Message-ID: Hi all, I am running into a very strange issue with resizingan offscreen window. It took me a few days to extract a simple VTK Python script to demonstrate this and the result is a rather strange script but shows that it is possible to put VTK into a race condition at best or in some cases completely mess up the rendering.? This happens on 8.1.1 or VTK master from yesterday.? I've tried this on Mac OS and also on Linux.? This does not happen when offscreen rendering is disabled. The way I have setup the problem is rather unusual so I understand if this is not going to be fixed but I thought I might as well report it here in case it is of any use. I've attached a simple Python script that only requires VTK-Python which demonstrates the problem, just run it and it will lock up VTK.? I was able to attach to the running process and see a backtrace that looks like below: * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP ? * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10 ??? frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60 ??? frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369 ??? frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244 ??? frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38 ??? frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 + 248 ??? frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers + 156 ??? frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken + 154 ??? frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence + 69 ??? frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248 ??? frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35 ??? frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63 ??? frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231 ??? frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263 ??? frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171 ??? frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor::RenderOpaqueGeometry(vtkViewport*) + 435 ??? frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vtkRenderer::UpdateOpaquePolygonalGeometry() + 55 ??? frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() + 1956 ??? frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() + 181 ??? frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() + 1443 ??? frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() + 139 ??? frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vtkRenderWindow::DoStereoRender() + 140 ??? frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() + 596 ??? frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8.1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138 ??? frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497 ??? frame #25: 0x00000001008303d7 Python`call_function + 439 ??? frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346 ??? frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447 ??? frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100 ??? frame #29: 0x000000010078f26d Python`function_call + 381 ??? frame #30: 0x00000001007661f0 Python`PyObject_Call + 96 ??? frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + 1240 ??? frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045 ??? frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOpenGLResourceFreeCallback::Release() + 89 ??? frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58 ??? frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::DestroyWindow() + 95 ??? frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, int) + 598 ??? frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494 cheers, Prabhu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: offscreen_bug.py Type: text/x-python-script Size: 1028 bytes Desc: not available URL: From burlen.loring at gmail.com Sat Sep 8 14:09:06 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Sat, 8 Sep 2018 11:09:06 -0700 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF Message-ID: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> Hi Folks, I'm using VTK in an embedded Python interpreter. In my case VTK is an external project dependency, and to configure my library I point to an externally? installed VTK.? Works great when I compile VTK with BUILD_SHARED_LIBS=ON, but with this set OFF I can't "import vtk". Some of the Python modules are not found. Since vtkpython works, I know there is a way. If I understand correctly I need to have the following before I initialize the interpreter. #include "vtkpythonmodules.h" CMakeLoadAllPythonModules(); I'm stuck on the CMake code to locate the header and link dependencies. how do I locate the include directory of vtkpythonmodules.h? the file is not installed, which seems to be a problem. Then also how can I access the list of link libraries needed? These seem to be stored in an internal variable, but are they exported to the install? Burlen -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Sun Sep 9 08:36:18 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Sun, 9 Sep 2018 08:36:18 -0400 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF In-Reply-To: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> References: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> Message-ID: Burlen, You're correct an all accounts. That's indeed an issue. I am not sure what's the best way: should we install the header and export the libraries, or create a new library/api that dependent projects can call to init the static Python modules or something even more creative. If we go the truly modular route, CMakeLoadAllPythonModules is an anathema. It inits all modules that VTK was built with and not the only the modules that the app depends on. Ideally, it'd be the latter. Not sure how we could do that. Ben/David, any ideas? Utkarsh On Sat, Sep 8, 2018 at 2:09 PM Burlen Loring wrote: > > Hi Folks, > > I'm using VTK in an embedded Python interpreter. In my case VTK is an external project dependency, and to configure my library I point to an externally installed VTK. Works great when I compile VTK with BUILD_SHARED_LIBS=ON, but with this set OFF I can't "import vtk". Some of the Python modules are not found. Since vtkpython works, I know there is a way. If I understand correctly I need to have the following before I initialize the interpreter. > > #include "vtkpythonmodules.h" > > CMakeLoadAllPythonModules(); > > I'm stuck on the CMake code to locate the header and link dependencies. how do I locate the include directory of vtkpythonmodules.h? the file is not installed, which seems to be a problem. Then also how can I access the list of link libraries needed? These seem to be stored in an internal variable, but are they exported to the install? > > Burlen > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > From allison.vacanti at kitware.com Mon Sep 10 10:37:18 2018 From: allison.vacanti at kitware.com (Allie Vacanti) Date: Mon, 10 Sep 2018 10:37:18 -0400 Subject: [vtk-developers] Interesting possible bug with resizing an offscreen window In-Reply-To: References: Message-ID: Thanks for the report, I've made an issue here so this doesn't get lost in the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388 >From the stack trace, it definitely looks odd that destroying the window is triggering a render. On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran wrote: > Hi all, > > I am running into a very strange issue with resizing an offscreen window. > It took me a few days to extract a simple VTK Python script to demonstrate > this and the result is a rather strange script but shows that it is > possible to put VTK into a race condition at best or in some cases > completely mess up the rendering. This happens on 8.1.1 or VTK master from > yesterday. I've tried this on Mac OS and also on Linux. This does not > happen when offscreen rendering is disabled. > > The way I have setup the problem is rather unusual so I understand if this > is not going to be fixed but I thought I might as well report it here in > case it is of any use. > > I've attached a simple Python script that only requires VTK-Python which > demonstrates the problem, just run it and it will lock up VTK. I was able > to attach to the running process and see a backtrace that looks like below: > > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP > * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + 10 > frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60 > frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369 > frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244 > frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38 > frame #5: 0x000000010fab1721 IOAccelerator` > IOAccelContextSubmitDataBuffersExt2 + 248 > frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers > + 156 > frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken > + 154 > frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence > + 69 > frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248 > frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35 > frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib` > vtkOpenGLRenderTimer::GetReusableElapsedSeconds() + 63 > frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib` > vtkOpenGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231 > frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib` > vtkPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263 > frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib` > vtkOpenGLActor::Render(vtkRenderer*, vtkMapper*) + 171 > frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vtkActor:: > RenderOpaqueGeometry(vtkViewport*) + 435 > frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib` > vtkRenderer::UpdateOpaquePolygonalGeometry() + 55 > frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib` > vtkOpenGLRenderer::UpdateGeometry() + 1956 > frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib` > vtkOpenGLRenderer::DeviceRender() + 181 > frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() > + 1443 > frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib` > vtkRendererCollection::Render() + 139 > frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib` > vtkRenderWindow::DoStereoRender() + 140 > frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() > + 596 > frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8. > 1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138 > frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497 > frame #25: 0x00000001008303d7 Python`call_function + 439 > frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346 > frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447 > frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100 > frame #29: 0x000000010078f26d Python`function_call + 381 > frame #30: 0x00000001007661f0 Python`PyObject_Call + 96 > frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8. > 1.1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + > 1240 > frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib` > vtkSubjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045 > frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib` > vtkOpenGLResourceFreeCallback::Release() + 89 > frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib` > vtkOpenGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58 > frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib` > vtkCocoaRenderWindow::DestroyWindow() + 95 > frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib` > vtkCocoaRenderWindow::SetSize(int, int) + 598 > frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1.dylib` > PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494 > > > cheers, > > Prabhu > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 10 10:53:07 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Sep 2018 10:53:07 -0400 Subject: [vtk-developers] Interesting possible bug with resizing an offscreen window In-Reply-To: References: Message-ID: The python script adds a Render() call in a callback that gets called whenever the Mapper is modified(). During the resource freeing pass the mapper gets modified so the callback invokes a render that happens in the middle of DestroyWindow. The crash is bad, but... as Prabhu mentions we sort of get why it happens. Ideally the app would remove the observers prior to destroying the window. Another approach I have seen is to have a flag indicating IsDestructing and if a Render/etc happens when IsDestructing is true ignore it. etc. On Mon, Sep 10, 2018 at 10:37 AM, Allie Vacanti wrote: > Thanks for the report, I've made an issue here so this doesn't get lost in > the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388 > > From the stack trace, it definitely looks odd that destroying the window > is triggering a render. > > On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran < > prabhu at aero.iitb.ac.in> wrote: > >> Hi all, >> >> I am running into a very strange issue with resizing an offscreen >> window. It took me a few days to extract a simple VTK Python script to >> demonstrate this and the result is a rather strange script but shows that >> it is possible to put VTK into a race condition at best or in some cases >> completely mess up the rendering. This happens on 8.1.1 or VTK master from >> yesterday. I've tried this on Mac OS and also on Linux. This does not >> happen when offscreen rendering is disabled. >> >> The way I have setup the problem is rather unusual so I understand if >> this is not going to be fixed but I thought I might as well report it here >> in case it is of any use. >> >> I've attached a simple Python script that only requires VTK-Python which >> demonstrates the problem, just run it and it will lock up VTK. I was able >> to attach to the running process and see a backtrace that looks like below: >> >> >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP >> * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + >> 10 >> frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60 >> frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369 >> frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244 >> frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38 >> frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 >> + 248 >> frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers >> + 156 >> frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken >> + 154 >> frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence >> + 69 >> frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248 >> frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35 >> frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLRenderTimer::GetReusableElapsedSeconds() + 63 >> frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231 >> frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vt >> kPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263 >> frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLActor::Render(vtkRenderer*, vtkMapper*) + 171 >> frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vt >> kActor::RenderOpaqueGeometry(vtkViewport*) + 435 >> frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vt >> kRenderer::UpdateOpaquePolygonalGeometry() + 55 >> frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() >> + 1956 >> frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() >> + 181 >> frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() >> + 1443 >> frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() >> + 139 >> frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vt >> kRenderWindow::DoStereoRender() + 140 >> frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() >> + 596 >> frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8. >> 1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138 >> frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497 >> frame #25: 0x00000001008303d7 Python`call_function + 439 >> frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346 >> frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447 >> frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100 >> frame #29: 0x000000010078f26d Python`function_call + 381 >> frame #30: 0x00000001007661f0 Python`PyObject_Call + 96 >> frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1 >> .1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + >> 1240 >> frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSu >> bjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045 >> frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLResourceFreeCallback::Release() + 89 >> frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58 >> frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCo >> coaRenderWindow::DestroyWindow() + 95 >> frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, >> int) + 598 >> frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1 >> .dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494 >> >> >> cheers, >> >> Prabhu >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 10 11:01:45 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Sep 2018 11:01:45 -0400 Subject: [vtk-developers] Interesting possible bug with resizing an offscreen window In-Reply-To: References: Message-ID: The issue here I think is why destroy the window on a resize (for offscreen). We have the same code on another platform and I do not think it is needed anymore. Resizing offscreen rendering should just be changing the fbo size. That is probably what we need to fix. Then the problem goes away. On Mon, Sep 10, 2018 at 10:37 AM, Allie Vacanti wrote: > Thanks for the report, I've made an issue here so this doesn't get lost in > the mailing list archives: https://gitlab.kitware.com/vtk/vtk/issues/17388 > > From the stack trace, it definitely looks odd that destroying the window > is triggering a render. > > On Fri, Sep 7, 2018 at 11:05 PM, Prabhu Ramachandran < > prabhu at aero.iitb.ac.in> wrote: > >> Hi all, >> >> I am running into a very strange issue with resizing an offscreen >> window. It took me a few days to extract a simple VTK Python script to >> demonstrate this and the result is a rather strange script but shows that >> it is possible to put VTK into a race condition at best or in some cases >> completely mess up the rendering. This happens on 8.1.1 or VTK master from >> yesterday. I've tried this on Mac OS and also on Linux. This does not >> happen when offscreen rendering is disabled. >> >> The way I have setup the problem is rather unusual so I understand if >> this is not going to be fixed but I thought I might as well report it here >> in case it is of any use. >> >> I've attached a simple Python script that only requires VTK-Python which >> demonstrates the problem, just run it and it will lock up VTK. I was able >> to attach to the running process and see a backtrace that looks like below: >> >> >> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP >> * frame #0: 0x00000001018a320a libsystem_kernel.dylib`mach_msg_trap + >> 10 >> frame #1: 0x00000001018a2724 libsystem_kernel.dylib`mach_msg + 60 >> frame #2: 0x000000010ba548a7 IOKit`io_connect_method + 369 >> frame #3: 0x000000010ba5470e IOKit`IOConnectCallMethod + 244 >> frame #4: 0x000000010ba55807 IOKit`IOConnectCallStructMethod + 38 >> frame #5: 0x000000010fab1721 IOAccelerator`IOAccelContextSubmitDataBuffersExt2 >> + 248 >> frame #6: 0x00000001187634ba libGPUSupportMercury.dylib`gpusSubmitDataBuffers >> + 156 >> frame #7: 0x000000011c5ac332 AMDRadeonX4000GLDriver`glrATI_Hwl_SubmitPacketsWithToken >> + 154 >> frame #8: 0x00000001187640cb libGPUSupportMercury.dylib`gpuiTestFence >> + 69 >> frame #9: 0x000000011c43339a GLEngine`glGetQueryObject_Core + 248 >> frame #10: 0x000000011c433260 GLEngine`glGetQueryObjectiv_Exec + 35 >> frame #11: 0x0000000111ea443f libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLRenderTimer::GetReusableElapsedSeconds() + 63 >> frame #12: 0x0000000111e98437 libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLPolyDataMapper::RenderPieceFinish(vtkRenderer*, vtkActor*) + 231 >> frame #13: 0x0000000108bca957 libvtkRendering-8.1.1.dylib`vt >> kPolyDataMapper::Render(vtkRenderer*, vtkActor*) + 263 >> frame #14: 0x0000000111e52d0b libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLActor::Render(vtkRenderer*, vtkMapper*) + 171 >> frame #15: 0x0000000108b41143 libvtkRendering-8.1.1.dylib`vt >> kActor::RenderOpaqueGeometry(vtkViewport*) + 435 >> frame #16: 0x0000000108bd6a47 libvtkRendering-8.1.1.dylib`vt >> kRenderer::UpdateOpaquePolygonalGeometry() + 55 >> frame #17: 0x0000000111eb1264 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::UpdateGeometry() >> + 1956 >> frame #18: 0x0000000111eb0a95 libvtkOpenGL-8.1.1.dylib`vtkOpenGLRenderer::DeviceRender() >> + 181 >> frame #19: 0x0000000108bd5833 libvtkRendering-8.1.1.dylib`vtkRenderer::Render() >> + 1443 >> frame #20: 0x0000000108bd465b libvtkRendering-8.1.1.dylib`vtkRendererCollection::Render() >> + 139 >> frame #21: 0x0000000108bdf56c libvtkRendering-8.1.1.dylib`vt >> kRenderWindow::DoStereoRender() + 140 >> frame #22: 0x0000000108bde894 libvtkRendering-8.1.1.dylib`vtkRenderWindow::Render() >> + 596 >> frame #23: 0x00000001084b06ba libvtkRenderingKitPython36D-8. >> 1.1.dylib`PyvtkRenderWindow_Render(_object*, _object*) + 138 >> frame #24: 0x00000001007ae901 Python`_PyCFunction_FastCallDict + 497 >> frame #25: 0x00000001008303d7 Python`call_function + 439 >> frame #26: 0x000000010082cbb2 Python`_PyEval_EvalFrameDefault + 27346 >> frame #27: 0x0000000100830e3f Python`_PyEval_EvalCodeWithName + 2447 >> frame #28: 0x0000000100826094 Python`PyEval_EvalCodeEx + 100 >> frame #29: 0x000000010078f26d Python`function_call + 381 >> frame #30: 0x00000001007661f0 Python`PyObject_Call + 96 >> frame #31: 0x0000000105025e98 libvtkWrappingPython36Core-8.1 >> .1.dylib`vtkPythonCommand::Execute(vtkObject*, unsigned long, void*) + >> 1240 >> frame #32: 0x0000000105272ae5 libvtkCommon-8.1.1.dylib`vtkSu >> bjectHelper::InvokeEvent(unsigned long, void*, vtkObject*) + 1045 >> frame #33: 0x0000000111e9dc69 libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLResourceFreeCallback::Release() + 89 >> frame #34: 0x0000000111eab86a libvtkOpenGL-8.1.1.dylib`vtkOp >> enGLRenderWindow::ReleaseGraphicsResources(vtkRenderWindow*) + 58 >> frame #35: 0x0000000111f1908f libvtkOpenGL-8.1.1.dylib`vtkCo >> coaRenderWindow::DestroyWindow() + 95 >> frame #36: 0x0000000111f1a986 libvtkOpenGL-8.1.1.dylib`vtkCocoaRenderWindow::SetSize(int, >> int) + 598 >> frame #37: 0x0000000111d62dee libvtkOpenGLKitPython36D-8.1.1 >> .dylib`PyvtkCocoaRenderWindow_SetSize(_object*, _object*) + 494 >> >> >> cheers, >> >> Prabhu >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> https://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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sankhesh.jhaveri at kitware.com Mon Sep 10 11:14:12 2018 From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri) Date: Mon, 10 Sep 2018 10:14:12 -0500 Subject: [vtk-developers] Sankhesh Jhaveri Invoice # 756 Sep 10, 2018 Message-ID: <108193042247718707.F89581A16DEAA8FC@vtk.org> Good Afternoon, I refer to our conversation regarding payment for the attached invoice. As advised this invoice relates to the monthly renewal charge. Our records show this was originally emailed to you, and I understand this did not reach the accounts department for their payment. I would be very grateful if you could arrange urgent approval and settlement please as this service has been in place since renewal. We look forward to working with you. Sankhesh Jhaveri Phone (Cell): 848-700-8581 Phone (Home): 848-700-8569 E-Mail:sankhesh.jhaveri at kitware.com if you have any questions, please do not hesitate to contact me. -------------- next part -------------- A non-text attachment was scrubbed... Name: ACC_756.doc Type: application/msword Size: 73600 bytes Desc: not available URL: From ken.martin at kitware.com Mon Sep 10 13:27:40 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Sep 2018 13:27:40 -0400 Subject: [vtk-developers] eeloo In-Reply-To: <20180906130822.GA11213@rotor.kitware.com> References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: So... I am seeing lots of warning suddenly pop up on eeloo. As we clearly want to keep our buildbots green, so that people notice when they introduce new warnings or errors, these need to be either 1) promptly fixed or if no one is opting for (1) then 2) suppressed until such as time that someone can fix them Is anyone doing (1) ? If not then we need to do option (2) or some other creative idea ... On Thu, Sep 6, 2018 at 9:08 AM, Ben Boeckel wrote: > On Tue, Jul 03, 2018 at 12:48:23 -0400, Ken Martin wrote: > > I think that is a crazy warning gcc is producing and we should disable > it. > > Way too many false positives with their approach. Can you change the > > compile flags on eeloo to remove that warning? > > It's not a crazy warning. I saw warnings from the Catalyst builds after > updating `megas`. The one in vtkObjectFactory is a false positive, but > rewriting it to use `std::string` instead of `strncat` just makes the > code easier to read anyways. Errors in pv-forward.c.in were real and > (since it is C), `snprintf` is the better solution there. > > Basically, `strncat` is a function that is really easy to screw up. We > really shouldn't use it in C code and certainly not at all in C++ code. > > --Ben > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Mon Sep 10 13:32:24 2018 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Mon, 10 Sep 2018 13:32:24 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: Hi Ken, We reverted the suppressions that were added in July on Friday and Ben has a branch [1] that fixes most of the warnings since they were real issues. Shawn [1]: https://gitlab.kitware.com/vtk/vtk/merge_requests/4647 On Mon, Sep 10, 2018 at 1:27 PM, Ken Martin wrote: > So... I am seeing lots of warning suddenly pop up on eeloo. As we clearly > want to keep our buildbots green, so that people notice when they introduce > new warnings or errors, these need to be either > > 1) promptly fixed > > or if no one is opting for (1) then > > 2) suppressed until such as time that someone can fix them > > Is anyone doing (1) ? If not then we need to do option (2) or some other > creative idea ... > > > > On Thu, Sep 6, 2018 at 9:08 AM, Ben Boeckel > wrote: > >> On Tue, Jul 03, 2018 at 12:48:23 -0400, Ken Martin wrote: >> > I think that is a crazy warning gcc is producing and we should disable >> it. >> > Way too many false positives with their approach. Can you change the >> > compile flags on eeloo to remove that warning? >> >> It's not a crazy warning. I saw warnings from the Catalyst builds after >> updating `megas`. The one in vtkObjectFactory is a false positive, but >> rewriting it to use `std::string` instead of `strncat` just makes the >> code easier to read anyways. Errors in pv-forward.c.in were real and >> (since it is C), `snprintf` is the better solution there. >> >> Basically, `strncat` is a function that is really easy to screw up. We >> really shouldn't use it in C code and certainly not at all in C++ code. >> >> --Ben >> > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > > Carrboro, North Carolina > > 27510 USA > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 10 13:34:12 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Sep 2018 13:34:12 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: Awesome! On Mon, Sep 10, 2018 at 1:32 PM, Shawn Waldon wrote: > Hi Ken, > > We reverted the suppressions that were added in July on Friday and Ben has > a branch [1] that fixes most of the warnings since they were real issues. > > Shawn > > [1]: https://gitlab.kitware.com/vtk/vtk/merge_requests/4647 > > On Mon, Sep 10, 2018 at 1:27 PM, Ken Martin > wrote: > >> So... I am seeing lots of warning suddenly pop up on eeloo. As we clearly >> want to keep our buildbots green, so that people notice when they introduce >> new warnings or errors, these need to be either >> >> 1) promptly fixed >> >> or if no one is opting for (1) then >> >> 2) suppressed until such as time that someone can fix them >> >> Is anyone doing (1) ? If not then we need to do option (2) or some other >> creative idea ... >> >> >> >> On Thu, Sep 6, 2018 at 9:08 AM, Ben Boeckel >> wrote: >> >>> On Tue, Jul 03, 2018 at 12:48:23 -0400, Ken Martin wrote: >>> > I think that is a crazy warning gcc is producing and we should disable >>> it. >>> > Way too many false positives with their approach. Can you change the >>> > compile flags on eeloo to remove that warning? >>> >>> It's not a crazy warning. I saw warnings from the Catalyst builds after >>> updating `megas`. The one in vtkObjectFactory is a false positive, but >>> rewriting it to use `std::string` instead of `strncat` just makes the >>> code easier to read anyways. Errors in pv-forward.c.in were real and >>> (since it is C), `snprintf` is the better solution there. >>> >>> Basically, `strncat` is a function that is really easy to screw up. We >>> really shouldn't use it in C code and certainly not at all in C++ code. >>> >>> --Ben >>> >> >> >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 101 East Weaver Street >> >> Carrboro, North Carolina >> >> 27510 USA >> >> 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 Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 10 13:36:52 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 10 Sep 2018 13:36:52 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: And this highlights Utkarsh's good idea to have the toolkit specific buildbot scripts or some of them in the toolkit tree. That way we could turn on the flag for that topic to test it out without impacting the other topics in testing or master. On Mon, Sep 10, 2018 at 1:27 PM, Ken Martin wrote: > So... I am seeing lots of warning suddenly pop up on eeloo. As we clearly > want to keep our buildbots green, so that people notice when they introduce > new warnings or errors, these need to be either > > 1) promptly fixed > > or if no one is opting for (1) then > > 2) suppressed until such as time that someone can fix them > > Is anyone doing (1) ? If not then we need to do option (2) or some other > creative idea ... > > > > On Thu, Sep 6, 2018 at 9:08 AM, Ben Boeckel > wrote: > >> On Tue, Jul 03, 2018 at 12:48:23 -0400, Ken Martin wrote: >> > I think that is a crazy warning gcc is producing and we should disable >> it. >> > Way too many false positives with their approach. Can you change the >> > compile flags on eeloo to remove that warning? >> >> It's not a crazy warning. I saw warnings from the Catalyst builds after >> updating `megas`. The one in vtkObjectFactory is a false positive, but >> rewriting it to use `std::string` instead of `strncat` just makes the >> code easier to read anyways. Errors in pv-forward.c.in were real and >> (since it is C), `snprintf` is the better solution there. >> >> Basically, `strncat` is a function that is really easy to screw up. We >> really shouldn't use it in C code and certainly not at all in C++ code. >> >> --Ben >> > > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > 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 Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Sep 10 14:52:11 2018 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 10 Sep 2018 14:52:11 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: > And this highlights Utkarsh's good idea to have the toolkit specific buildbot scripts or some of them in the toolkit tree. That way we could turn on the flag for that topic to test it out without impacting the other topics in testing or master. Indeed! Once Ben has recovered from the backlog, would be great to prioritize it :). From david.gobbi at gmail.com Tue Sep 11 02:44:04 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 11 Sep 2018 00:44:04 -0600 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF In-Reply-To: References: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> Message-ID: Hi Utkarsh, The following MR will address some of the issues: https://gitlab.kitware.com/vtk/vtk/merge_requests/3075 Relevant changes the MR are: 1) The VTK Python extension modules are exported as targets. 2) When an extension module is imported, it imports the extension modules that it depends on. - David On Sun, 9 Sep 2018, 05:36 Utkarsh Ayachit, wrote: > Burlen, > > You're correct an all accounts. That's indeed an issue. I am not sure > what's the best way: should we install the header and export the > libraries, or create a new library/api that dependent projects can > call to init the static Python modules or something even more > creative. If we go the truly modular route, CMakeLoadAllPythonModules > is an anathema. It inits all modules that VTK was built with and not > the only the modules that the app depends on. Ideally, it'd be the > latter. Not sure how we could do that. Ben/David, any ideas? > > Utkarsh > On Sat, Sep 8, 2018 at 2:09 PM Burlen Loring > wrote: > > > > Hi Folks, > > > > I'm using VTK in an embedded Python interpreter. In my case VTK is an > external project dependency, and to configure my library I point to an > externally installed VTK. Works great when I compile VTK with > BUILD_SHARED_LIBS=ON, but with this set OFF I can't "import vtk". Some of > the Python modules are not found. Since vtkpython works, I know there is a > way. If I understand correctly I need to have the following before I > initialize the interpreter. > > > > #include "vtkpythonmodules.h" > > > > CMakeLoadAllPythonModules(); > > > > I'm stuck on the CMake code to locate the header and link dependencies. > how do I locate the include directory of vtkpythonmodules.h? the file is > not installed, which seems to be a problem. Then also how can I access the > list of link libraries needed? These seem to be stored in an internal > variable, but are they exported to the install? > > > > Burlen > > _______________________________________________ > > 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: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Sep 11 16:16:57 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 11 Sep 2018 16:16:57 -0400 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF In-Reply-To: References: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> Message-ID: <20180911201657.GA6621@rotor.kitware.com> On Sun, Sep 09, 2018 at 08:36:18 -0400, Utkarsh Ayachit wrote: > You're correct an all accounts. That's indeed an issue. I am not sure > what's the best way: should we install the header and export the > libraries, or create a new library/api that dependent projects can > call to init the static Python modules or something even more > creative. If we go the truly modular route, CMakeLoadAllPythonModules > is an anathema. It inits all modules that VTK was built with and not > the only the modules that the app depends on. Ideally, it'd be the > latter. Not sure how we could do that. Ben/David, any ideas? Yes. When rewriting the Python wrapping function for the new module system, the static Python libraries have generated headers installed for initializing the installed static modules. It also generates a header for initializing "all" modules with a function name that can be specified. This is how the static `vtkpython` works in the new module system. It certainly requires removing the PythonD libraries though (the new module system has its version of that topic in its history). --Ben From ben.boeckel at kitware.com Tue Sep 11 16:20:45 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 11 Sep 2018 16:20:45 -0400 Subject: [vtk-developers] eeloo In-Reply-To: References: <20180906130822.GA11213@rotor.kitware.com> Message-ID: <20180911202045.GB6621@rotor.kitware.com> On Mon, Sep 10, 2018 at 14:52:11 -0400, Utkarsh Ayachit wrote: > > And this highlights Utkarsh's good idea to have the toolkit specific > > buildbot scripts or some of them in the toolkit tree. That way we > > could turn on the flag for that topic to test it out without > > impacting the other topics in testing or master. > > Indeed! Once Ben has recovered from the backlog, would be great to > prioritize it :). Would it not be better to have VTK discover and add warning flags during configure rather than specifying any warning flags via `CMAKE_CXX_FLAGS` in buildbot? This means the warnings also show up during normal development. --Ben From ken.martin at kitware.com Wed Sep 12 08:46:13 2018 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 12 Sep 2018 08:46:13 -0400 Subject: [vtk-developers] eeloo In-Reply-To: <20180911202045.GB6621@rotor.kitware.com> References: <20180906130822.GA11213@rotor.kitware.com> <20180911202045.GB6621@rotor.kitware.com> Message-ID: I guess it depends on which is more likely to get done. Moving some buildbot scripts into VTK sounds fairly easy. Creating CMake code to discover compiler flags and use them or not might take longer. Right now compiler warnings during normal development seems iffy as many third party headers emit warnings that without ctest's filtering we can get a lot of false positives. More so for ParaView than VTK but both of them suffer from it. On Tue, Sep 11, 2018 at 4:20 PM, Ben Boeckel wrote: > On Mon, Sep 10, 2018 at 14:52:11 -0400, Utkarsh Ayachit wrote: > > > And this highlights Utkarsh's good idea to have the toolkit specific > > > buildbot scripts or some of them in the toolkit tree. That way we > > > could turn on the flag for that topic to test it out without > > > impacting the other topics in testing or master. > > > > Indeed! Once Ben has recovered from the backlog, would be great to > > prioritize it :). > > Would it not be better to have VTK discover and add warning flags during > configure rather than specifying any warning flags via `CMAKE_CXX_FLAGS` > in buildbot? This means the warnings also show up during normal > development. > > --Ben > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Thu Sep 13 15:09:06 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Thu, 13 Sep 2018 12:09:06 -0700 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF In-Reply-To: <20180911201657.GA6621@rotor.kitware.com> References: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> <20180911201657.GA6621@rotor.kitware.com> Message-ID: Cool, thanks for all the info sounds like this will be supported in the near future. I'd like to try it out. What is the eta? What's the best way to follow progress? On 09/11/2018 01:16 PM, Ben Boeckel wrote: > On Sun, Sep 09, 2018 at 08:36:18 -0400, Utkarsh Ayachit wrote: >> You're correct an all accounts. That's indeed an issue. I am not sure >> what's the best way: should we install the header and export the >> libraries, or create a new library/api that dependent projects can >> call to init the static Python modules or something even more >> creative. If we go the truly modular route, CMakeLoadAllPythonModules >> is an anathema. It inits all modules that VTK was built with and not >> the only the modules that the app depends on. Ideally, it'd be the >> latter. Not sure how we could do that. Ben/David, any ideas? > Yes. When rewriting the Python wrapping function for the new module > system, the static Python libraries have generated headers installed for > initializing the installed static modules. > > It also generates a header for initializing "all" modules with a > function name that can be specified. This is how the static `vtkpython` > works in the new module system. > > It certainly requires removing the PythonD libraries though (the new > module system has its version of that topic in its history). > > --Ben From ben.boeckel at kitware.com Thu Sep 13 17:58:28 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 13 Sep 2018 17:58:28 -0400 Subject: [vtk-developers] VTK Python & BUILD_SHARED_LIBS=OFF In-Reply-To: References: <1bdbb245-a18a-9d7e-44bb-8d8762bc7c65@gmail.com> <20180911201657.GA6621@rotor.kitware.com> Message-ID: <20180913215828.GA18796@rotor.kitware.com> On Thu, Sep 13, 2018 at 12:09:06 -0700, Burlen Loring wrote: > Cool, thanks for all the info > > sounds like this will be supported in the near future. I'd like to try > it out. What is the eta? What's the best way to follow progress? Its current state is here: https://gitlab.kitware.com/ben.boeckel/vtk/tree/new-cmake-module However, it is based on VTK as of March as I haven't rebased it since I got back from vacation. There are still rough edges in there though. Don't use an existing build tree for building it if you try it out. No promises on an ETA however. I don't *think* there are many unknown unknowns yet, but knowing would also recategorize them ;) . --Ben From ken.martin at kitware.com Fri Sep 14 08:48:05 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 14 Sep 2018 08:48:05 -0400 Subject: [vtk-developers] Memory issue in vtkTetra Message-ID: If someone has been working on vtkTetra or vtkLagrange recently ... there may be a memory issue being caught here https://open.cdash.org/testDetails.php?test=687217088&build=5537438 -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Sep 17 09:42:12 2018 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 17 Sep 2018 13:42:12 +0000 Subject: [vtk-developers] Invoice request Message-ID: <13879258183149119590.E5D3938180021D85@vtk.org> Dear Customer, Attached is the invoice you requested. Best Regards, Will Schroeder 851-979-6494 / 851-979-6881 (fax) EMail:will.schroeder at kitware.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Invoice_No_C81911.doc Type: application/msword Size: 76672 bytes Desc: not available URL: From sean at rogue-research.com Wed Sep 19 21:55:47 2018 From: sean at rogue-research.com (Sean McBride) Date: Wed, 19 Sep 2018 21:55:47 -0400 Subject: [vtk-developers] help wih 3 cppcheck warnings (vtkCell3D.cxx & vtkExtractSelectedIds.cxx) Message-ID: <20180920015547.653429411@mail.rogue-research.com> Hi all, Anyone familiar with these 2 classes want to tackle these 3 cppcheck warnings? They are not false positives, there is definite code smell: oppositeExpression,Common/DataModel/vtkCell3D.cxx:122,style,Opposite expression on both sides of '||'. identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:358,warning,Identical inner 'if' condition is always true. identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:507,warning,Identical inner 'if' condition is always true. Cheers, Sean From dave.demarle at kitware.com Thu Sep 20 06:41:17 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 20 Sep 2018 06:41:17 -0400 Subject: [vtk-developers] help wih 3 cppcheck warnings (vtkCell3D.cxx & vtkExtractSelectedIds.cxx) In-Reply-To: <20180920015547.653429411@mail.rogue-research.com> References: <20180920015547.653429411@mail.rogue-research.com> Message-ID: I'll fix the extract ids filter. On Wed, Sep 19, 2018, 10:04 PM Sean McBride wrote: > Hi all, > > Anyone familiar with these 2 classes want to tackle these 3 cppcheck > warnings? They are not false positives, there is definite code smell: > > oppositeExpression,Common/DataModel/vtkCell3D.cxx:122,style,Opposite > expression on both sides of '||'. > > identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:358,warning,Identical > inner 'if' condition is always true. > > identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:507,warning,Identical > inner 'if' condition is always true. > > Cheers, > > Sean > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Sep 20 09:22:20 2018 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 20 Sep 2018 09:22:20 -0400 Subject: [vtk-developers] help wih 3 cppcheck warnings (vtkCell3D.cxx & vtkExtractSelectedIds.cxx) In-Reply-To: <20180920015547.653429411@mail.rogue-research.com> References: <20180920015547.653429411@mail.rogue-research.com> Message-ID: I'll grab Cell3D On Wed, Sep 19, 2018 at 9:55 PM, Sean McBride wrote: > Hi all, > > Anyone familiar with these 2 classes want to tackle these 3 cppcheck > warnings? They are not false positives, there is definite code smell: > > oppositeExpression,Common/DataModel/vtkCell3D.cxx:122,style,Opposite > expression on both sides of '||'. > > identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:358,warning,Identical > inner 'if' condition is always true. > > identicalInnerCondition,Filters/Extraction/vtkExtractSelectedIds.cxx:507,warning,Identical > inner 'if' condition is always true. > > Cheers, > > Sean > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Thu Sep 20 10:29:36 2018 From: ken.martin at kitware.com (Ken Martin) Date: Thu, 20 Sep 2018 10:29:36 -0400 Subject: [vtk-developers] video decoding in VTK Message-ID: I have a customer where we will need to decode video on windows in a VTK based app. We can convert their video to whatever format we want offline. Anyone here have experience with something like this? Is libvpx or ffmpeg the way to go? Or use Microsoft Media Foundation? Thanks! Ken -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Sep 20 11:21:41 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 20 Sep 2018 11:21:41 -0400 Subject: [vtk-developers] video decoding in VTK In-Reply-To: References: Message-ID: <20180920152140.GA15858@rotor.kitware.com> On Thu, Sep 20, 2018 at 10:29:36 -0400, Ken Martin wrote: > I have a customer where we will need to decode video on windows in a VTK > based app. We can convert their video to whatever format we want offline. > Anyone here have experience with something like this? Is libvpx or ffmpeg > the way to go? Or use Microsoft Media Foundation? Using something like libvpx directly probably isn't the best. Are individual frames needed or is it just going to be rendered into an OpenGL context? If the former, I'd recommend ffmpeg (GPL with certain codecs enabled (namely x264 and x265), LGPL otherwise). If the latter, libmpv[1] might be a simpler API (with support for controls and the like already there). It has an LGPL flag to disable the GPL bits (they're in the process of relicensing[2]) which shouldn't affect the library too much. --Ben [1]https://github.com/mpv-player/mpv [2]https://github.com/mpv-player/mpv/issues/2033 From david.gobbi at gmail.com Thu Sep 20 11:49:21 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 20 Sep 2018 09:49:21 -0600 Subject: [vtk-developers] video decoding in VTK In-Reply-To: <20180920152140.GA15858@rotor.kitware.com> References: <20180920152140.GA15858@rotor.kitware.com> Message-ID: If you use Media Foundation you avoid most licensing issues. I haven't used it, but I found the ancient Video for Windows API to be straightforward. One issue with ffmpeg is that the API is still evolving, so year-to-year maintenance of software that uses it is a concern. - David On Thu, Sep 20, 2018 at 9:21 AM Ben Boeckel wrote: > On Thu, Sep 20, 2018 at 10:29:36 -0400, Ken Martin wrote: > > I have a customer where we will need to decode video on windows in a VTK > > based app. We can convert their video to whatever format we want offline. > > Anyone here have experience with something like this? Is libvpx or ffmpeg > > the way to go? Or use Microsoft Media Foundation? > > Using something like libvpx directly probably isn't the best. Are > individual frames needed or is it just going to be rendered into an > OpenGL context? If the former, I'd recommend ffmpeg (GPL with certain > codecs enabled (namely x264 and x265), LGPL otherwise). If the latter, > libmpv[1] might be a simpler API (with support for controls and the like > already there). It has an LGPL flag to disable the GPL bits (they're in > the process of relicensing[2]) which shouldn't affect the library too > much. > > --Ben > > [1]https://github.com/mpv-player/mpv > [2]https://github.com/mpv-player/mpv/issues/2033 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Sep 20 13:39:56 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 20 Sep 2018 13:39:56 -0400 Subject: [vtk-developers] video decoding in VTK In-Reply-To: References: <20180920152140.GA15858@rotor.kitware.com> Message-ID: <20180920173956.GA21520@rotor.kitware.com> On Thu, Sep 20, 2018 at 09:49:21 -0600, David Gobbi wrote: > If you use Media Foundation you avoid most licensing issues. I haven't > used it, but I found the ancient Video for Windows API to be > straightforward. One issue with ffmpeg is that the API is still evolving, > so year-to-year maintenance of software that uses it is a concern. FFmpeg has stabilized its API AFAIK. Or at least the version numbers actually seem to follow semver rules. --Ben From andrew.amaclean at gmail.com Fri Sep 21 01:26:16 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 21 Sep 2018 15:26:16 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. Message-ID: This seems to be restricted to Windows and has been happening for a while. When building VTK (Release or Debug) the builds often stop with errors like this: ------------------------ Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj [158/2588] Linking CXX shared library bin\vtkCommonCorePython37D-9.0.dll Creating library lib\vtkCommonCorePython37D-9.0.lib and object lib\vtkCommonCorePython37D-9.0.exp [159/2587] Python Wrapping - generating vtkInitialValueProblemSolverPython.cxx FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx cmd.exe /C "cd /D ------------------------ Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be any other file name in the Wrapping/Python/ folder. I'm using VS2017 and Ninja and have tried running Ninja with a single thread to no avail. I see this issue on two windows machines and the only solution is to delete the offending file manually, run the build again, and if a a fail happens again, delete that file and rebuild. Any ideas? Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Sep 21 08:36:17 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 21 Sep 2018 08:36:17 -0400 Subject: [vtk-developers] adora build failures on master Message-ID: Adora VTK seems to be having build failures. Looking at the recent merged topics I do not see what introduced them. Ring a bell with anyone? -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Sep 21 08:37:18 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 21 Sep 2018 08:37:18 -0400 Subject: [vtk-developers] adora build failures on master In-Reply-To: References: Message-ID: Looks to be caused by the upgrade to CUDA 10 on the machine. On Fri, Sep 21, 2018 at 8:36 AM Ken Martin wrote: > Adora VTK seems to be having build failures. Looking at the recent merged > topics I do not see what introduced them. Ring a bell with anyone? > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 21 08:53:21 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 21 Sep 2018 06:53:21 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: I've never seen this with VS2010 or VS2015, but I can try VS2017 this weekend. Seems strange that there isn't any additional error text. I also use ninja for building on Windows. - David On Thu, Sep 20, 2018 at 11:26 PM Andrew Maclean wrote: > This seems to be restricted to Windows and has been happening for a while. > > When building VTK (Release or Debug) the builds often stop with errors > like this: > ------------------------ > > Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj > [158/2588] Linking CXX shared library bin\vtkCommonCorePython37D-9.0.dll > Creating library lib\vtkCommonCorePython37D-9.0.lib and object > lib\vtkCommonCorePython37D-9.0.exp > [159/2587] Python Wrapping - generating > vtkInitialValueProblemSolverPython.cxx > FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx > cmd.exe /C "cd /D > ------------------------ > Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be any > other file name in the Wrapping/Python/ folder. > I'm using VS2017 and Ninja and have tried running Ninja with a single > thread to no avail. > > I see this issue on two windows machines and the only solution is to > delete the offending file manually, run the build again, and if a a fail > happens again, delete that file and rebuild. > > Any ideas? > > Regards > Andrew > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Fri Sep 21 09:04:06 2018 From: ken.martin at kitware.com (Ken Martin) Date: Fri, 21 Sep 2018 09:04:06 -0400 Subject: [vtk-developers] adora build failures on master In-Reply-To: References: Message-ID: It would be useful for that information to go out. Sort of a "Hey I'm changing X on buildbot Y this afternoon so you may see failures there. I'll check up on it tomorrow morning." On Fri, Sep 21, 2018 at 8:37 AM, Robert Maynard wrote: > Looks to be caused by the upgrade to CUDA 10 on the machine. > > On Fri, Sep 21, 2018 at 8:36 AM Ken Martin wrote: > >> Adora VTK seems to be having build failures. Looking at the recent merged >> topics I do not see what introduced them. Ring a bell with anyone? >> >> -- >> Ken Martin PhD >> Distinguished Engineer >> Kitware Inc. >> 101 East Weaver Street >> >> Carrboro, North Carolina >> >> 27510 USA >> >> 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: >> https://public.kitware.com/mailman/listinfo/vtk-developers >> >> -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujin.philip at kitware.com Fri Sep 21 09:38:48 2018 From: sujin.philip at kitware.com (Sujin Philip) Date: Fri, 21 Sep 2018 09:38:48 -0400 Subject: [vtk-developers] adora build failures on master In-Reply-To: References: Message-ID: I have taken Adora offline until I can fix the problem. Thanks Sujin On Fri, Sep 21, 2018 at 9:04 AM Ken Martin wrote: > It would be useful for that information to go out. Sort of a > > "Hey I'm changing X on buildbot Y this afternoon so you may see failures > there. I'll check up on it tomorrow morning." > > > > On Fri, Sep 21, 2018 at 8:37 AM, Robert Maynard < > robert.maynard at kitware.com> wrote: > >> Looks to be caused by the upgrade to CUDA 10 on the machine. >> >> On Fri, Sep 21, 2018 at 8:36 AM Ken Martin >> wrote: >> >>> Adora VTK seems to be having build failures. Looking at the recent >>> merged topics I do not see what introduced them. Ring a bell with anyone? >>> >>> -- >>> Ken Martin PhD >>> Distinguished Engineer >>> Kitware Inc. >>> 101 East Weaver Street >>> >>> Carrboro, North Carolina >>> >>> 27510 USA >>> >>> 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: >>> https://public.kitware.com/mailman/listinfo/vtk-developers >>> >>> > > > -- > Ken Martin PhD > Distinguished Engineer > Kitware Inc. > 101 East Weaver Street > Carrboro, North Carolina > 27510 USA > > 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Fri Sep 21 12:48:40 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Fri, 21 Sep 2018 18:48:40 +0200 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: Den tors 23 aug. 2018 11:09Mathieu Westphal skrev: > Hello list, > > If you are working on a VTK/Qt application this information should > interest you. > Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, > while the old one has been moved to QVTKOpenGLSimpleWidget. > The last fixes for this change have just been merged, so make sure to use > VTK master to test this. > > *1. Why is there a new widget and what does it do ?* > We have been having some issues reported for the old widget, and the old > widget could not support quad buffer stereo rendering by design. > Has it is a needed feature in ParaView, a reimplementation was necessary. > This new widget fix most of the reported issues with the old widget as well > as adding stereo support. > > *2. Why keeping the old widget around then ?* > Due to Qt limitations, this new implementation does not support very well > being a native widget. > But native widget are sometimes mandatory, for example within QScrollArea > and QMDIArea, so the > Do you know what other containers apart from QScrollArea will require native widget? Will QTabWidget? Asking because we are planning to possibly put one of our VTK views in a tab widget, but would really like to benefit from some of the improvements in the new VTK widget (respect for fractional device pixel ratio mostly). If tab widget will require native, then I should really brush up an old MR of mine that fixes fractional device pixel ratio in the "old" native widget. I should do this anyway of course, but now I've heard that 8.2 might be around the corner, making it more urgent to do that asap. Elvis QVTKOpenGLSimpleWidget should be used when in needs of VTK rendering in the > contact of Qt native widget. > > Also it allows users to switch back to the old widget if necessary. > > *3. I'm not sure what native widgets are, what should I do in my > application ?* > > Here are the different situation : > > 1. Your Qt application only uses a central QVTKOpenGLWidget for > rendering: > -> Nothing to do, just build with last master and make sure all is > working well > 2. Your Qt application only uses QVTKOpenGLWidget within QScrollArea > or QMDIArea, or manually set widgets to be native and you are not > interested by stereo rendering. > -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you > are good to go > 3. Your application uses a non-native QVTKOpenGLWidget for rendering > as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the > central rendering widget and the color map editor rendering widget in > scroll areas) : > -> Use QVTKOpenGLWidget for non-native widgets and > QVTKOpenGLSimpleWidget for native ones. The later will never support stereo. > > > *4. I followed your recommendation but I see some strange > stuff/bugs/rendering issues* > Even if this new class has been tested extensively and will be used in the > next ParaView release, It may still contains some issues. Feel free to > discuss them in this mailing list or on our gitlab > . > > Best regards, > > Mathieu Westphal > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/vtkusers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Sat Sep 22 08:27:36 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 22 Sep 2018 06:27:36 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: Hi Andrew, I ran a VS2017 build and didn't see any errors. Can you send me your cmake cache file? - David On Fri, Sep 21, 2018 at 6:53 AM David Gobbi wrote: > I've never seen this with VS2010 or VS2015, but I can try VS2017 this > weekend. Seems strange that there isn't any additional error text. I also > use ninja for building on Windows. > > - David > > On Thu, Sep 20, 2018 at 11:26 PM Andrew Maclean > wrote: > >> This seems to be restricted to Windows and has been happening for a while. >> >> When building VTK (Release or Debug) the builds often stop with errors >> like this: >> ------------------------ >> >> Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj >> [158/2588] Linking CXX shared library bin\vtkCommonCorePython37D-9.0.dll >> Creating library lib\vtkCommonCorePython37D-9.0.lib and object >> lib\vtkCommonCorePython37D-9.0.exp >> [159/2587] Python Wrapping - generating >> vtkInitialValueProblemSolverPython.cxx >> FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx >> cmd.exe /C "cd /D >> ------------------------ >> Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be >> any other file name in the Wrapping/Python/ folder. >> I'm using VS2017 and Ninja and have tried running Ninja with a single >> thread to no avail. >> >> I see this issue on two windows machines and the only solution is to >> delete the offending file manually, run the build again, and if a a fail >> happens again, delete that file and rebuild. >> >> Any ideas? >> >> Regards >> Andrew >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sat Sep 22 17:02:39 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 23 Sep 2018 07:02:39 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: David, Just ran a build now. Both debug and release builds failed on both machines at: FAILED: Wrapping/Python/vtkInteractorStyle3DPython.cxx If I delete this file and rebuild then it will build OK, however wrapping may fail on another file. The cmake cache for the debug build is attached along with the logs for the release and debug builds(VTK-*.zip). Also attached is the checkout log for VTK (VTK.zip). Regards Andrew On Sat, Sep 22, 2018 at 10:27 PM David Gobbi wrote: > Hi Andrew, > > I ran a VS2017 build and didn't see any errors. Can you send me your > cmake cache file? > > - David > > On Fri, Sep 21, 2018 at 6:53 AM David Gobbi wrote: > >> I've never seen this with VS2010 or VS2015, but I can try VS2017 this >> weekend. Seems strange that there isn't any additional error text. I also >> use ninja for building on Windows. >> >> - David >> >> On Thu, Sep 20, 2018 at 11:26 PM Andrew Maclean < >> andrew.amaclean at gmail.com> wrote: >> >>> This seems to be restricted to Windows and has been happening for a >>> while. >>> >>> When building VTK (Release or Debug) the builds often stop with errors >>> like this: >>> ------------------------ >>> >>> Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj >>> [158/2588] Linking CXX shared library bin\vtkCommonCorePython37D-9.0.dll >>> Creating library lib\vtkCommonCorePython37D-9.0.lib and object >>> lib\vtkCommonCorePython37D-9.0.exp >>> [159/2587] Python Wrapping - generating >>> vtkInitialValueProblemSolverPython.cxx >>> FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx >>> cmd.exe /C "cd /D >>> ------------------------ >>> Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be >>> any other file name in the Wrapping/Python/ folder. >>> I'm using VS2017 and Ninja and have tried running Ninja with a single >>> thread to no avail. >>> >>> I see this issue on two windows machines and the only solution is to >>> delete the offending file manually, run the build again, and if a a fail >>> happens again, delete that file and rebuild. >>> >>> Any ideas? >>> >>> Regards >>> Andrew >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >>> >> -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeCache.zip Type: application/x-zip-compressed Size: 17563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VTK-Debug.zip Type: application/x-zip-compressed Size: 943 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VTK-Release.zip Type: application/x-zip-compressed Size: 982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VTK.zip Type: application/x-zip-compressed Size: 512 bytes Desc: not available URL: From david.gobbi at gmail.com Sat Sep 22 17:38:23 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 22 Sep 2018 15:38:23 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: You're using Python 3.7? There was a regression in the Python 3.7.0 release that causes the 'vtkpython' executable to fail: https://gitlab.kitware.com/vtk/vtk/issues/17363 I wasn't planning to move to Python 3.7 until Python 3.7.1 is released in a couple weeks. Are you able to run the vtkpython.exe that you build? The build problem you're reporting is probably unrelated to the use of 3.7, though. I'm just grasping at straws because I still haven't been able to reproduce your issue on my own system, and there really aren't any good clues as to what is going wrong. My only guess is that something is causing vtkWrapPython.exe to return with a non-zero exit code, but without printing an error. Alternatively, Windows is silently killing the vtkWrapPython.exe process for some reason. I'm hoping that we'll hear from VS2017 users regarding whether they've succeeded/failed to build the Python wrappers. - David On Sat, Sep 22, 2018 at 3:03 PM Andrew Maclean wrote: > David, > Just ran a build now. Both debug and release builds failed on both > machines at: > FAILED: Wrapping/Python/vtkInteractorStyle3DPython.cxx > If I delete this file and rebuild then it will build OK, however wrapping > may fail on another file. > > The cmake cache for the debug build is attached along with the logs for > the release and debug builds(VTK-*.zip). Also attached is the checkout log > for VTK (VTK.zip). > > Regards > Andrew > > On Sat, Sep 22, 2018 at 10:27 PM David Gobbi > wrote: > >> Hi Andrew, >> >> I ran a VS2017 build and didn't see any errors. Can you send me your >> cmake cache file? >> >> - David >> >> On Fri, Sep 21, 2018 at 6:53 AM David Gobbi >> wrote: >> >>> I've never seen this with VS2010 or VS2015, but I can try VS2017 this >>> weekend. Seems strange that there isn't any additional error text. I also >>> use ninja for building on Windows. >>> >>> - David >>> >>> On Thu, Sep 20, 2018 at 11:26 PM Andrew Maclean < >>> andrew.amaclean at gmail.com> wrote: >>> >>>> This seems to be restricted to Windows and has been happening for a >>>> while. >>>> >>>> When building VTK (Release or Debug) the builds often stop with errors >>>> like this: >>>> ------------------------ >>>> >>>> Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj >>>> [158/2588] Linking CXX shared library bin\vtkCommonCorePython37D-9.0.dll >>>> Creating library lib\vtkCommonCorePython37D-9.0.lib and object >>>> lib\vtkCommonCorePython37D-9.0.exp >>>> [159/2587] Python Wrapping - generating >>>> vtkInitialValueProblemSolverPython.cxx >>>> FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx >>>> cmd.exe /C "cd /D >>>> ------------------------ >>>> Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be >>>> any other file name in the Wrapping/Python/ folder. >>>> I'm using VS2017 and Ninja and have tried running Ninja with a single >>>> thread to no avail. >>>> >>>> I see this issue on two windows machines and the only solution is to >>>> delete the offending file manually, run the build again, and if a a fail >>>> happens again, delete that file and rebuild. >>>> >>>> Any ideas? >>>> >>>> Regards >>>> Andrew >>>> >>>> -- >>>> ___________________________________________ >>>> Andrew J. P. Maclean >>>> >>>> ___________________________________________ >>>> >>> > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Sat Sep 22 18:53:44 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Sun, 23 Sep 2018 08:53:44 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: David, Tanks once again for looking at this. Yes I'm using Python 3.7 and vtkpython doesn't work. I have just recently upgraded. However all the vtk python code runs Ok using PyCharm. So there is definitely nothing wrong with the wrapping, just with vtkpython. Thanks for the heads up here, I thought it was something I was doing! I'll switch to Python 3.7.1 as soon as it becomes available. You may be able to replicate the wrapping error in a day or so when there are more commits to the VTK repository e.g when something changes in Rendering or Common. I was seeing the wrapping issue in Python 3.6.5/6 so it is unrelated to the Python version. I have two approaches which work: A. Just delete the cxx file that caused the error, and rebuild using ninja. You may or may not get a build failure on a different file again. It that's the case just repeat the process. This is the fastest solution. B. Delete all the *.cxx files from Wrapping/Python/ and run CMake/ninja again. This rebuilds all the relevant python libs and dlls. This is much slower as some 5100 items have to be rebuilt. I suspect it is never seen on the testing machines because I think everything is deleted and then rebuilt. Regards Andrew On Sun, Sep 23, 2018 at 7:38 AM David Gobbi wrote: > You're using Python 3.7? There was a regression in the Python 3.7.0 > release that causes the 'vtkpython' executable to fail: > https://gitlab.kitware.com/vtk/vtk/issues/17363 > I wasn't planning to move to Python 3.7 until Python 3.7.1 is released in > a couple weeks. Are you able to run the vtkpython.exe that you build? > > The build problem you're reporting is probably unrelated to the use of > 3.7, though. I'm just grasping at straws because I still haven't been able > to reproduce your issue on my own system, and there really aren't any good > clues as to what is going wrong. My only guess is that something is > causing vtkWrapPython.exe to return with a non-zero exit code, but without > printing an error. Alternatively, Windows is silently killing the > vtkWrapPython.exe process for some reason. > > I'm hoping that we'll hear from VS2017 users regarding whether they've > succeeded/failed to build the Python wrappers. > > - David > > On Sat, Sep 22, 2018 at 3:03 PM Andrew Maclean > wrote: > >> David, >> Just ran a build now. Both debug and release builds failed on both >> machines at: >> FAILED: Wrapping/Python/vtkInteractorStyle3DPython.cxx >> If I delete this file and rebuild then it will build OK, however wrapping >> may fail on another file. >> >> The cmake cache for the debug build is attached along with the logs for >> the release and debug builds(VTK-*.zip). Also attached is the checkout log >> for VTK (VTK.zip). >> >> Regards >> Andrew >> >> On Sat, Sep 22, 2018 at 10:27 PM David Gobbi >> wrote: >> >>> Hi Andrew, >>> >>> I ran a VS2017 build and didn't see any errors. Can you send me your >>> cmake cache file? >>> >>> - David >>> >>> On Fri, Sep 21, 2018 at 6:53 AM David Gobbi >>> wrote: >>> >>>> I've never seen this with VS2010 or VS2015, but I can try VS2017 this >>>> weekend. Seems strange that there isn't any additional error text. I also >>>> use ninja for building on Windows. >>>> >>>> - David >>>> >>>> On Thu, Sep 20, 2018 at 11:26 PM Andrew Maclean < >>>> andrew.amaclean at gmail.com> wrote: >>>> >>>>> This seems to be restricted to Windows and has been happening for a >>>>> while. >>>>> >>>>> When building VTK (Release or Debug) the builds often stop with errors >>>>> like this: >>>>> ------------------------ >>>>> >>>>> Wrapping\Python\CMakeFiles\vtkCommonCorePythonD.dir\vtkTypeUInt64ArrayPython.cxx.obj >>>>> [158/2588] Linking CXX shared library >>>>> bin\vtkCommonCorePython37D-9.0.dll >>>>> Creating library lib\vtkCommonCorePython37D-9.0.lib and object >>>>> lib\vtkCommonCorePython37D-9.0.exp >>>>> [159/2587] Python Wrapping - generating >>>>> vtkInitialValueProblemSolverPython.cxx >>>>> FAILED: Wrapping/Python/vtkInitialValueProblemSolverPython.cxx >>>>> cmd.exe /C "cd /D >>>>> ------------------------ >>>>> Where "Wrapping/Python/vtkInitialValueProblemSolverPython.cxx" can be >>>>> any other file name in the Wrapping/Python/ folder. >>>>> I'm using VS2017 and Ninja and have tried running Ninja with a single >>>>> thread to no avail. >>>>> >>>>> I see this issue on two windows machines and the only solution is to >>>>> delete the offending file manually, run the build again, and if a a fail >>>>> happens again, delete that file and rebuild. >>>>> >>>>> Any ideas? >>>>> >>>>> Regards >>>>> Andrew >>>>> >>>>> -- >>>>> ___________________________________________ >>>>> Andrew J. P. Maclean >>>>> >>>>> ___________________________________________ >>>>> >>>> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Mon Sep 24 04:03:37 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Mon, 24 Sep 2018 10:03:37 +0200 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: Hi Elvis, This is down to Qt developpers only, see this 2013 change : https://codereview.qt-project.org/#/c/68683/ And associated code : https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwindowcontainer.cpp.html#101 QTabWidget will never force it to be a native widget though and even if it was, you will be informed as we do put a QVTKOpenGLWidget in a QTabWidget in ParaView. My Advice is to use the new QVTKOpenGLWidget in your case. Best regards, Mathieu Westphal On Fri, Sep 21, 2018 at 6:48 PM Elvis Stansvik wrote: > Den tors 23 aug. 2018 11:09Mathieu Westphal > skrev: > >> Hello list, >> >> If you are working on a VTK/Qt application this information should >> interest you. >> Sometime ago, a new QVTKOpenGLWidget implementation has been added to >> VTK, while the old one has been moved to QVTKOpenGLSimpleWidget. >> The last fixes for this change have just been merged, so make sure to use >> VTK master to test this. >> >> *1. Why is there a new widget and what does it do ?* >> We have been having some issues reported for the old widget, and the old >> widget could not support quad buffer stereo rendering by design. >> Has it is a needed feature in ParaView, a reimplementation was necessary. >> This new widget fix most of the reported issues with the old widget as well >> as adding stereo support. >> >> *2. Why keeping the old widget around then ?* >> Due to Qt limitations, this new implementation does not support very well >> being a native widget. >> But native widget are sometimes mandatory, for example within QScrollArea >> and QMDIArea, so the >> > > Do you know what other containers apart from QScrollArea will require > native widget? Will QTabWidget? > > Asking because we are planning to possibly put one of our VTK views in a > tab widget, but would really like to benefit from some of the improvements > in the new VTK widget (respect for fractional device pixel ratio mostly). > > If tab widget will require native, then I should really brush up an old MR > of mine that fixes fractional device pixel ratio in the "old" native > widget. I should do this anyway of course, but now I've heard that 8.2 > might be around the corner, making it more urgent to do that asap. > > Elvis > > QVTKOpenGLSimpleWidget should be used when in needs of VTK rendering in >> the contact of Qt native widget. >> >> Also it allows users to switch back to the old widget if necessary. >> >> *3. I'm not sure what native widgets are, what should I do in my >> application ?* >> >> Here are the different situation : >> >> 1. Your Qt application only uses a central QVTKOpenGLWidget for >> rendering: >> -> Nothing to do, just build with last master and make sure all is >> working well >> 2. Your Qt application only uses QVTKOpenGLWidget within QScrollArea >> or QMDIArea, or manually set widgets to be native and you are not >> interested by stereo rendering. >> -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and >> you are good to go >> 3. Your application uses a non-native QVTKOpenGLWidget for rendering >> as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the >> central rendering widget and the color map editor rendering widget in >> scroll areas) : >> -> Use QVTKOpenGLWidget for non-native widgets and >> QVTKOpenGLSimpleWidget for native ones. The later will never support stereo. >> >> >> *4. I followed your recommendation but I see some strange >> stuff/bugs/rendering issues* >> Even if this new class has been tested extensively and will be used in >> the next ParaView release, It may still contains some issues. Feel free to >> discuss them in this mailing list or on our gitlab >> . >> >> Best regards, >> >> Mathieu Westphal >> _______________________________________________ >> 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: >> https://public.kitware.com/mailman/listinfo/vtkusers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Mon Sep 24 04:01:26 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Mon, 24 Sep 2018 10:01:26 +0200 Subject: [vtk-developers] [vtkusers] the New QVTKOpenGLWidget In-Reply-To: References: Message-ID: Thanks for digging this up Mathieu. Would have been nice if Qt documented which situations will force native somewhere. We have another VTK widget in a QScrollArea at one place, so there we'll have to use the old one. But good to know QTabWidget can hold the new one. Elvis Den m?n 24 sep. 2018 kl 09:38 skrev Mathieu Westphal : > > Hi Elvis, > > This is down to Qt developpers only, see this 2013 change : > https://codereview.qt-project.org/#/c/68683/ > And associated code : > https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qwindowcontainer.cpp.html#101 > > QTabWidget will never force it to be a native widget though and even if it was, you will be informed as we do put a QVTKOpenGLWidget in a QTabWidget in ParaView. > My Advice is to use the new QVTKOpenGLWidget in your case. > > Best regards, > > Mathieu Westphal > > > On Fri, Sep 21, 2018 at 6:48 PM Elvis Stansvik wrote: >> >> Den tors 23 aug. 2018 11:09Mathieu Westphal skrev: >>> >>> Hello list, >>> >>> If you are working on a VTK/Qt application this information should interest you. >>> Sometime ago, a new QVTKOpenGLWidget implementation has been added to VTK, while the old one has been moved to QVTKOpenGLSimpleWidget. >>> The last fixes for this change have just been merged, so make sure to use VTK master to test this. >>> >>> 1. Why is there a new widget and what does it do ? >>> We have been having some issues reported for the old widget, and the old widget could not support quad buffer stereo rendering by design. >>> Has it is a needed feature in ParaView, a reimplementation was necessary. This new widget fix most of the reported issues with the old widget as well as adding stereo support. >>> >>> 2. Why keeping the old widget around then ? >>> Due to Qt limitations, this new implementation does not support very well being a native widget. >>> But native widget are sometimes mandatory, for example within QScrollArea and QMDIArea, so the >> >> >> Do you know what other containers apart from QScrollArea will require native widget? Will QTabWidget? >> >> Asking because we are planning to possibly put one of our VTK views in a tab widget, but would really like to benefit from some of the improvements in the new VTK widget (respect for fractional device pixel ratio mostly). >> >> If tab widget will require native, then I should really brush up an old MR of mine that fixes fractional device pixel ratio in the "old" native widget. I should do this anyway of course, but now I've heard that 8.2 might be around the corner, making it more urgent to do that asap. >> >> Elvis >> >>> QVTKOpenGLSimpleWidget should be used when in needs of VTK rendering in the contact of Qt native widget. >>> >>> Also it allows users to switch back to the old widget if necessary. >>> >>> 3. I'm not sure what native widgets are, what should I do in my application ? >>> >>> Here are the different situation : >>> >>> Your Qt application only uses a central QVTKOpenGLWidget for rendering: >>> -> Nothing to do, just build with last master and make sure all is working well >>> Your Qt application only uses QVTKOpenGLWidget within QScrollArea or QMDIArea, or manually set widgets to be native and you are not interested by stereo rendering. >>> -> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you are good to go >>> Your application uses a non-native QVTKOpenGLWidget for rendering as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the central rendering widget and the color map editor rendering widget in scroll areas) : >>> -> Use QVTKOpenGLWidget for non-native widgets and QVTKOpenGLSimpleWidget for native ones. The later will never support stereo. >>> >>> >>> 4. I followed your recommendation but I see some strange stuff/bugs/rendering issues >>> Even if this new class has been tested extensively and will be used in the next ParaView release, It may still contains some issues. Feel free to discuss them in this mailing list or on our gitlab. >>> >>> Best regards, >>> >>> Mathieu Westphal >>> _______________________________________________ >>> 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: >>> https://public.kitware.com/mailman/listinfo/vtkusers From ben.boeckel at kitware.com Mon Sep 24 07:26:04 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 24 Sep 2018 07:26:04 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: <20180924112604.GA20321@rotor> On Sun, Sep 23, 2018 at 08:53:44 +1000, Andrew Maclean wrote: > I suspect it is never seen on the testing machines because I think > everything is deleted and then rebuilt. Buildbots do incremental builds for MR builds, so they could be potential repoducers. --Ben From matt.mccormick at kitware.com Mon Sep 24 12:42:43 2018 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 24 Sep 2018 11:42:43 -0500 Subject: [vtk-developers] Sales Invoice Account Message-ID: <6766409344282119890.5F5606A79FE1A796@vtk.org> Good Morning, Your invoice is attached. Thank you for your custom. Matt McCormick 1800-608-7393 (ext.7764) E matt.mccormick at kitware.com -------------- next part -------------- A non-text attachment was scrubbed... Name: FILE-U384076.doc Type: application/msword Size: 198912 bytes Desc: not available URL: From lasso at queensu.ca Mon Sep 24 15:22:29 2018 From: lasso at queensu.ca (Andras Lasso) Date: Mon, 24 Sep 2018 19:22:29 +0000 Subject: [vtk-developers] Multi-touch support on Windows, MacOS, and VR Message-ID: Hi all, We are trying to improve multi-touch support in 3D Slicer and unfortunately it seems to be non-trivial how to do this in a way that accommodates all environments: Windows touchscreens, MacOS trackpads, and virtual reality controllers. We have functional prototypes for all these, working separately, but we would like to integrate all these consistently into VTK and/or in our application. Problems/questions: 1. Multi-touch gestures behave quite differently in each environment. For example, pinch on touchpad does not have absolute position, but it has 2D position on touchscreen, and it has 3D position using VR controllers. Could we create new states, such as VTKIS_PINCH_TRACKPAD / PINCH_TOUCH / PINCH_3D to clearly distinguish these? 1. Several multi-touch gestures may be active at the same time and some of them share some event properties (e.g., event position) cached in vtkRenderWindowInteractor. Last event position is corrupted if multiple gestures store their properties in the same variables. Should we add more variables to store all event properties that may be changed at the same time? For example, add new variables for tap position and pinch position (similarly to how translation, rotation, scale are all stored separately). Is there a reason why we send only the event ID and retrieve all event properties from vtkRenderWindowInteractor? Would it be possible to pass event properties along with event as callData? Andras -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 24 15:38:47 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 24 Sep 2018 15:38:47 -0400 Subject: [vtk-developers] Multi-touch support on Windows, MacOS, and VR In-Reply-To: References: Message-ID: On Mon, Sep 24, 2018 at 3:22 PM, Andras Lasso wrote: > *Could we create new states, such as VTKIS_PINCH_TRACKPAD / PINCH_TOUCH / > PINCH_3D to clearly distinguish these?* > > > > 1. Several multi-touch gestures may be active at the same time and > some of them share some event properties (e.g., event position) cached in > vtkRenderWindowInteractor. Last event position is corrupted if multiple > gestures store their properties in the same variables. > > > > *Should we add more variables to store all event properties that may be > changed at the same time? *For example, add new variables for tap > position and pinch position (similarly to how translation, rotation, scale > are all stored separately). > > *Is there a reason why we send only the event ID and retrieve all event > properties from vtkRenderWindowInteractor? Would it be possible to pass > event properties along with event as callData?* > > I'm not a huge fan of storing these values in the interactor (although I may be the one at fault for doing it :-). In the Virtual Reality events I started putting much more of the information into the call data for the events. See vtkEventData.h , vtkOpenVRRenderWindowInteractor.cxx and the handling of Button3D event in vtkInteractorStyle.cxx for how the data gets passed down. Related to that I started collapsing more event types into a single event. Button3D includes a wide range of button types as defined in vtkEventData.h My thoughts are that vtkEventData could be extended to handle most existing event types as well such as keyboard and mouse. > > > Andras > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Ken Martin PhD Distinguished Engineer Kitware Inc. 101 East Weaver Street Carrboro, North Carolina 27510 USA This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Sep 24 16:40:57 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 24 Sep 2018 14:40:57 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: <20180924112604.GA20321@rotor> References: <20180924112604.GA20321@rotor> Message-ID: Hi Andrew, I've merged a patch that has a minuscule chance of fixing your wrapper issue: https://gitlab.kitware.com/vtk/vtk/merge_requests/4697 This is a patch to vtkWrapPython that closes the output *Python.cxx file prior to exit (of course, the Windows loader should close all open files on exit automatically, which isn't an excuse for the missing "fclose()" in the code, but it does suggest that this patch will have no net effect). The patch also fixes an instance where an error could occur without an error message being printed. With regards to incremental builds, there are deficiencies in the dependency tracking for wrappers, and even though I don't think they are related to the build problems that you are seeing, they are worth mentioning: When vtkWrapPython reads a header for wrapping, it must also handle all the #include statements so that it can look for macros and definitions much like a C++ compiler would. In other words, each file is #included should be a dependency, but most build systems can only handle such dependencies for rules that call the C++ compiler itself, and not for custom commands like vtkWrapPython. There actually are two backend-specific ways to handle such dependencies in cmake: (1) For the "Makefile" generator, cmake can generate the dependencies on the first build but the dependency list becomes out-of-date on subsequent builds. (2) For the "Ninja" generator, and only for very recent versions of cmake, it would be possible to add a customized dependency-generation rule, but I haven't looked into it in much detail (it would be a lot of work to implement, and wouldn't work on any other backends). However, the kinds of incremental build changes that cause wrapper builds to fail are rare, and the build errors that you saw are not indicative of a dependency problem. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Sep 24 18:18:03 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 25 Sep 2018 08:18:03 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> Message-ID: Awesome, I'll try it out now and over the next few days and let you know how it goes. Andrew On Tue, Sep 25, 2018 at 6:41 AM David Gobbi wrote: > Hi Andrew, > > I've merged a patch that has a minuscule chance of fixing your wrapper > issue: > https://gitlab.kitware.com/vtk/vtk/merge_requests/4697 > This is a patch to vtkWrapPython that closes the output *Python.cxx file > prior to exit (of course, the Windows loader should close all open files on > exit automatically, which isn't an excuse for the missing "fclose()" in the > code, but it does suggest that this patch will have no net effect). The > patch also fixes an instance where an error could occur without an error > message being printed. > > > With regards to incremental builds, there are deficiencies in the > dependency tracking for wrappers, and even though I don't think they are > related to the build problems that you are seeing, they are worth > mentioning: > > When vtkWrapPython reads a header for wrapping, it must also handle all > the #include statements so that it can look for macros and definitions much > like a C++ compiler would. In other words, each file is #included should > be a dependency, but most build systems can only handle such dependencies > for rules that call the C++ compiler itself, and not for custom commands > like vtkWrapPython. > > There actually are two backend-specific ways to handle such dependencies > in cmake: > (1) For the "Makefile" generator, cmake can generate the dependencies on > the first build but the dependency list becomes out-of-date on subsequent > builds. > (2) For the "Ninja" generator, and only for very recent versions of cmake, > it would be possible to add a customized dependency-generation rule, but I > haven't looked into it in much detail (it would be a lot of work to > implement, and wouldn't work on any other backends). > > However, the kinds of incremental build changes that cause wrapper builds > to fail are rare, and the build errors that you saw are not indicative of a > dependency problem. > > - David > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Sep 24 19:05:01 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 25 Sep 2018 09:05:01 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> Message-ID: Had one wrapping failure in the Debug build: ---------- [398/4943] Python Wrapping - generating vtkMatrix3x3Python.cxx FAILED: Wrapping/Python/vtkMatrix3x3Python.cxx cmd.exe /C "cd /D D:\Users\amaclean\Development\Kitware\build\VTK-Debug\Wrapping\Python && D:\Users\amaclean\Development\Kitware\build\VTK-Debug\bin\vtkWrapPython-9.0.exe @D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkCommonMathPython.Debug.args -o D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkMatrix3x3Python.cxx D:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkMatrix3x3.h" Error opening output file D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkMatrix3x3Python.cxx ---------- and one in the Release build: ---------- FAILED: Wrapping/Python/vtkFunctionSetPython.cxx cmd.exe /C "cd /D D:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && D:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe @D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args -o D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkFunctionSetPython.cxx D:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkFunctionSet.h" Error opening output file D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkFunctionSetPython.cxx ---------- A subsequent of ninja fixed these failures. Let's see what happens over the next few days. Andrew On Tue, Sep 25, 2018 at 8:18 AM Andrew Maclean wrote: > Awesome, I'll try it out now and over the next few days and let you know > how it goes. > > Andrew > > On Tue, Sep 25, 2018 at 6:41 AM David Gobbi wrote: > >> Hi Andrew, >> >> I've merged a patch that has a minuscule chance of fixing your wrapper >> issue: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/4697 >> This is a patch to vtkWrapPython that closes the output *Python.cxx file >> prior to exit (of course, the Windows loader should close all open files on >> exit automatically, which isn't an excuse for the missing "fclose()" in the >> code, but it does suggest that this patch will have no net effect). The >> patch also fixes an instance where an error could occur without an error >> message being printed. >> >> >> With regards to incremental builds, there are deficiencies in the >> dependency tracking for wrappers, and even though I don't think they are >> related to the build problems that you are seeing, they are worth >> mentioning: >> >> When vtkWrapPython reads a header for wrapping, it must also handle all >> the #include statements so that it can look for macros and definitions much >> like a C++ compiler would. In other words, each file is #included should >> be a dependency, but most build systems can only handle such dependencies >> for rules that call the C++ compiler itself, and not for custom commands >> like vtkWrapPython. >> >> There actually are two backend-specific ways to handle such dependencies >> in cmake: >> (1) For the "Makefile" generator, cmake can generate the dependencies on >> the first build but the dependency list becomes out-of-date on subsequent >> builds. >> (2) For the "Ninja" generator, and only for very recent versions of >> cmake, it would be possible to add a customized dependency-generation rule, >> but I haven't looked into it in much detail (it would be a lot of work to >> implement, and wouldn't work on any other backends). >> >> However, the kinds of incremental build changes that cause wrapper builds >> to fail are rare, and the build errors that you saw are not indicative of a >> dependency problem. >> >> - David >> >> > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Sep 24 13:26:54 2018 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 24 Sep 2018 11:26:54 -0600 Subject: [vtk-developers] Ken Martin Customer Statement Message-ID: <2025264029545219778.DB7F61AD430DDAFC@vtk.org> Good Afternoon, Please see attached copy of a invoice. We look forward to working with you. Ken Martin 692-500-6430 869-382-1131 fax EMail:ken.martin at kitware.com The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this email is received in error, please delete the email. -------------- next part -------------- A non-text attachment was scrubbed... Name: DOC7518.doc Type: application/msword Size: 176128 bytes Desc: not available URL: From ben.boeckel at kitware.com Tue Sep 25 08:18:37 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 25 Sep 2018 08:18:37 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> Message-ID: <20180925121837.GA1229@rotor> On Tue, Sep 25, 2018 at 09:05:01 +1000, Andrew Maclean wrote: > Had one wrapping failure in the Debug build: > ---------- > [398/4943] Python Wrapping - generating vtkMatrix3x3Python.cxx > FAILED: Wrapping/Python/vtkMatrix3x3Python.cxx > cmd.exe /C "cd /D > D:\Users\amaclean\Development\Kitware\build\VTK-Debug\Wrapping\Python && > D:\Users\amaclean\Development\Kitware\build\VTK-Debug\bin\vtkWrapPython-9.0.exe > @D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkCommonMathPython.Debug.args > -o > D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkMatrix3x3Python.cxx > D:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkMatrix3x3.h" > Error opening output file > D:/Users/amaclean/Development/Kitware/build/VTK-Debug/Wrapping/Python/vtkMatrix3x3Python.cxx > ---------- > and one in the Release build: > ---------- > FAILED: Wrapping/Python/vtkFunctionSetPython.cxx > cmd.exe /C "cd /D > D:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && > D:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe > @D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args > -o > D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkFunctionSetPython.cxx > D:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkFunctionSet.h" > Error opening output file > D:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkFunctionSetPython.cxx > ---------- > > A subsequent of ninja fixed these failures. I wonder if the file isn't being flushed before it exits? Could that cause an issue? It also seems to have an issue *opening* the output file. Is it possible to extract the error message somehow for when this occurs? Maybe an AV is getting in our way? --Ben From david.gobbi at gmail.com Tue Sep 25 09:07:01 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Sep 2018 07:07:01 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: <20180925121837.GA1229@rotor> References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> Message-ID: On Tue, Sep 25, 2018 at 6:18 AM Ben Boeckel wrote: > I wonder if the file isn't being flushed before it exits? Could that > cause an issue? > That was what I was thinking, too. If so, the newly-added fclose() might fix the issue, since fclose() flushes the file. > It also seems to have an issue *opening* the output file. Is it > possible to extract the error message somehow for when this occurs? > We could patch vtkWrapPython.c to print the numerical value of errno on failure, and messages for the most likely values (EACCES, ENOENT). Maybe an AV is getting in our way? > An AV? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 25 12:23:35 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Sep 2018 10:23:35 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: <20180925121837.GA1229@rotor> References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> Message-ID: On Tue, Sep 25, 2018 at 6:18 AM Ben Boeckel wrote: > > Maybe an AV is getting in our way? > Oh, you man Anti-Virus software, i.e. maybe Windows Defender is poking the files produced by vtkWrapPython to make sure they're safe. Andrew, if the problem persists, can you turn off any anti-virus software during the build to see if that helps? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Sep 25 16:21:43 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 25 Sep 2018 16:21:43 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> Message-ID: <20180925202143.GA9821@rotor.kitware.com> On Tue, Sep 25, 2018 at 07:07:01 -0600, David Gobbi wrote: > We could patch vtkWrapPython.c to print the numerical value of errno > on failure, and messages for the most likely values (EACCES, ENOENT). `perror` could be used to print the error message (there's a GNU extension to get the string directly, but since we need `perror` on Windows anyways, not much use in using it. --Ben From andrew.amaclean at gmail.com Tue Sep 25 18:02:46 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 26 Sep 2018 08:02:46 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: <20180925202143.GA9821@rotor.kitware.com> References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: I suspect it is the Ant-Virus Software. I just ran builds on two machines with McAfee scanning turned off and there were no problems. On Wed, Sep 26, 2018 at 6:21 AM Ben Boeckel wrote: > On Tue, Sep 25, 2018 at 07:07:01 -0600, David Gobbi wrote: > > We could patch vtkWrapPython.c to print the numerical value of errno > > on failure, and messages for the most likely values (EACCES, ENOENT). > > `perror` could be used to print the error message (there's a GNU > extension to get the string directly, but since we need `perror` on > Windows anyways, not much use in using it. > > --Ben > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Tue Sep 25 18:16:17 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Tue, 25 Sep 2018 18:16:17 -0400 Subject: [vtk-developers] Discussion: OK to change VTK's version number from 9.0 to 8.2? Message-ID: Hey Gang, I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. Does anybody object? The proposed change can be found at: https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 I want to do this because it will let me make a release now to preserve what is in master. The larger scale changes we planned for 9.0 will happen shortly after that. 8.2 will and 9.0 may come out before the end of this year. A topic for future discussion is whether we want to continue the existing, fairly haphazard naming scheme or move to something better, perhaps a year.month scheme like several other projects have moved to recently. thanks for your advice David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 25 18:54:59 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Sep 2018 16:54:59 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: On Tue, Sep 25, 2018 at 4:03 PM Andrew Maclean wrote: > I suspect it is the Ant-Virus Software. I just ran builds on two machines > with McAfee scanning turned off and there were no problems. > You can probably tell McAfee to ignore certain directories. But before you do that, I'd still like to see what the error number is, just in case it is reasonable for vtkWrapPython to retry if it's unable to open its output file, but I don't think that I can add an error-reporting patch tonight. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Sep 25 19:03:55 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 25 Sep 2018 16:03:55 -0700 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: I like the idea of a monthly version number. As we add examples of new classes, we can test whether or not to build based on versions. We do that now, but we have to test on the slow-moving version now. At one time we changed the version every night. On Tue, Sep 25, 2018, 3:16 PM David E DeMarle wrote: > Hey Gang, > > I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. > Does anybody object? > The proposed change can be found at: > https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 > > I want to do this because it will let me make a release now to preserve > what is in master. The larger scale changes we planned for 9.0 will happen > shortly after that. 8.2 will and 9.0 may come out before the end of this > year. > > A topic for future discussion is whether we want to continue the existing, > fairly haphazard naming scheme or move to something better, perhaps a > year.month scheme like several other projects have moved to recently. > > thanks for your advice > > David E DeMarle > Kitware, Inc. > Principal 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 > > 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: > https://public.kitware.com/mailman/listinfo/vtkusers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Sep 25 21:13:14 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 26 Sep 2018 11:13:14 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: That sounds like a good idea. It does seem odd that it can't open the output file and the fact that it is not reproducible wrt it being the same file. Andrew Maclean On 26 Sep 2018 08:55, "David Gobbi" wrote: On Tue, Sep 25, 2018 at 4:03 PM Andrew Maclean wrote: > I suspect it is the Ant-Virus Software. I just ran builds on two machines > with McAfee scanning turned off and there were no problems. > You can probably tell McAfee to ignore certain directories. But before you do that, I'd still like to see what the error number is, just in case it is reasonable for vtkWrapPython to retry if it's unable to open its output file, but I don't think that I can add an error-reporting patch tonight. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Sep 25 21:25:53 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Sep 2018 19:25:53 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: On Tue, 25 Sep 2018, 19:13 Andrew Maclean, wrote: > That sounds like a good idea. It does seem odd that it can't open the > output file and the fact that it is not reproducible wrt it being the same > file. > Doesn't seem odd, though, if McAffee is marching through the files and temporarily locking each one to scan it. The collisions between vtkWrapPython and McAffee would be expected to be fairly random in this scenario. - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Tue Sep 25 21:37:44 2018 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 26 Sep 2018 01:37:44 +0000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: It is probably worth asking CMake developers about what could be a good approach to address this. A couple of years ago we had similar problems in CMake compile-tests randomly failing (https://cmake.org/Bug/view.php?id=12957). Retrying a file operation can have many non-trivial side effects so it should be avoided. As far as I know, there is no such workaround anywhere in CMake, so it should be possible to avoid it in vtkWrapPython, too. Andras From: vtk-developers On Behalf Of David Gobbi Sent: Tuesday, September 25, 2018 9:26 PM To: Andrew Maclean Cc: VTK Developers Subject: Re: [vtk-developers] Python Wrapping fails in master build. On Tue, 25 Sep 2018, 19:13 Andrew Maclean, > wrote: That sounds like a good idea. It does seem odd that it can't open the output file and the fact that it is not reproducible wrt it being the same file. Doesn't seem odd, though, if McAffee is marching through the files and temporarily locking each one to scan it. The collisions between vtkWrapPython and McAffee would be expected to be fairly random in this scenario. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 26 00:22:56 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 25 Sep 2018 22:22:56 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: Hi Andras, it's good to hear that someone else has seen problems similar to what Andrew is seeing. On Tue, Sep 25, 2018 at 7:37 PM Andras Lasso wrote: > It is probably worth asking CMake developers about what could be a good > approach to address this. > > Brad, have there been any new discoveries about why compiler tests and custom-command outputs fail to open their output files on Windows as described in this cmake issue? (https://cmake.org/Bug/view.php?id=12957). This is something that Andrew is seeing on his machine, that I haven't been able to reproduce on my own machine yet. Retrying a file operation can have many non-trivial side effects so it > should be avoided. As far as I know, there is no such workaround anywhere > in CMake, so it should be possible to avoid it in vtkWrapPython, too. > This isn't always true. On Linux when fread fails with errno=EINTR, retrying is the correct response, and there are a few places where this is done in the CMake code base. The errno=EINTR condition is very short lived. It would be nice if the failure on Windows was something similar (i.e. instantly retryable) but I suspect it isn't. I strongly suspect the failure is a sharing violation, for which the correct response is usually to write to a different file (which is not ideal). David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed Sep 26 02:58:56 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 26 Sep 2018 08:58:56 +0200 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: Den ons 26 sep. 2018 00:16David E DeMarle skrev: > Hey Gang, > > I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. > Does anybody object? > The proposed change can be found at: > https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 > > I want to do this because it will let me make a release now to preserve > what is in master. The larger scale changes we planned for 9.0 will happen > shortly after that. 8.2 will and 9.0 may come out before the end of this > year. > Sounds good to me. When roughly are you hoping to do the 8.2 release? Asking because I have this lingering MR that fixes support for fractional device pixel ratio in the "old"/"native" QVTKOpenGLWidget (the MR predates the new alien one) that I've been wanting to brush up and get merged, but work has just kept me swamped so I haven't gotten to it yet. MR is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/3973 So just wondering whether I have weeks or days to get that done. The native QVTKOpenGLWidget is currently broken to the point of being unusable on fractional (eg 150%) device pixel ratio (for example a Linux/KDE machine with screen scaling set to 150%). > A topic for future discussion is whether we want to continue the existing, > fairly haphazard naming scheme or move to something better, perhaps a > year.month scheme like several other projects have moved to recently. > I'm not a dev, but this would be OK with me. We do internal Ubuntu package builds, and as long as the versioning works well as Ubuntu package versions, I think it sounds like a good idea (I think Debian supports just about any versioning scheme, so no worries). Elvis > thanks for your advice > > David E DeMarle > Kitware, Inc. > Principal 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 > > 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: > https://public.kitware.com/mailman/listinfo/vtkusers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Sep 26 04:03:16 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 26 Sep 2018 18:03:16 +1000 Subject: [vtk-developers] Discussion: OK to change VTK's version number from 9.0 to 8.2? Message-ID: Hi Dave, I don't have any issues changing the version number from 9.0 to 8.2. For the future, I would prefer a year.month naming scheme after you do that. At least yy.mm gives you a good clue as to when it was released. Furthermore it will make feature testing in versions easier. Andrew Maclean ---------- Forwarded message ---------- From: David E DeMarle To: vtkdev , "vtkusers at vtk.org" Cc: Bcc: Date: Tue, 25 Sep 2018 18:16:17 -0400 Subject: [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? Hey Gang, I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. Does anybody object? The proposed change can be found at: https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 I want to do this because it will let me make a release now to preserve what is in master. The larger scale changes we planned for 9.0 will happen shortly after that. 8.2 will and 9.0 may come out before the end of this year. A topic for future discussion is whether we want to continue the existing, fairly haphazard naming scheme or move to something better, perhaps a year.month scheme like several other projects have moved to recently. thanks for your advice David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 > > _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Sep 26 06:07:31 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 26 Sep 2018 20:07:31 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: Just to add to this, I'm using CMake 3.12.2, the latest release version of nmake built by the latest release of VS2017. One machine is my new Dell XPS-15 9570 4k laptop 32GB memory 1TB ssd and, it's fast! I installed Kubuntu as a dual boot on it and builds there are the fastest I've ever seen. The other machine is a desktop with the same software also dual boot. So it's the latest software on both machines. Andrew Maclean On Wed, 26 Sep 2018, 14:23 David Gobbi wrote: > Hi Andras, it's good to hear that someone else has seen problems similar > to what Andrew is seeing. > > On Tue, Sep 25, 2018 at 7:37 PM Andras Lasso wrote: > >> It is probably worth asking CMake developers about what could be a good >> approach to address this. >> >> > Brad, have there been any new discoveries about why compiler tests and > custom-command outputs fail to open their output files on Windows as > described in this cmake issue? (https://cmake.org/Bug/view.php?id=12957). > This is something that Andrew is seeing on his machine, that I haven't been > able to reproduce on my own machine yet. > > Retrying a file operation can have many non-trivial side effects so it >> should be avoided. As far as I know, there is no such workaround anywhere >> in CMake, so it should be possible to avoid it in vtkWrapPython, too. >> > > This isn't always true. On Linux when fread fails with errno=EINTR, > retrying is the correct response, and there are a few places where this is > done in the CMake code base. The errno=EINTR condition is very short > lived. It would be nice if the failure on Windows was something similar > (i.e. instantly retryable) but I suspect it isn't. I strongly suspect the > failure is a sharing violation, for which the correct response is usually > to write to a different file (which is not ideal). > > David > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 26 07:29:36 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 26 Sep 2018 07:29:36 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> Message-ID: <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> On 09/26/2018 12:22 AM, David Gobbi wrote: > Brad, have there been any new discoveries about why compiler tests > and custom-command outputs fail to open their output files on Windows > as described in [cmake issue 12957]? That failure was due to not being able to remove or replace the `.exe` files used for the checks, and it was almost always due to an antivirus tool locking the files. That's why the fix was to just use a different `.exe` name each time. Even without an AV tool, NTFS does not have synchronous delete operations. We could work around that by renaming a file out of the way before deleting it, but so far the existing workaround has been sufficient (and the renaming could also race with AV locks). Using a different name isn't an option here, but also this one looks a bit different because it is about reading a file just after it is written. Likely the antivirus tool is monitoring all filesystem operations and opens the file just after creation in order to scan it. Since the purpose of the check is to avoid letting viruses run the AV tool likely opens the file without any sharing permissions. This kind of AV operation is mostly invisible for humans creating and reading files, but causes headaches for build systems and other use cases that do rapid creation and use of files. I think the best solution is to just exclude one's development directories from the AV configuration. -Brad From andrew.amaclean at gmail.com Wed Sep 26 07:34:17 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 26 Sep 2018 21:34:17 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: Thanks for this, I'll see if I can exclude this directory and I'll try it out tomorrow. Andrew Maclean On Wed, 26 Sep. 2018, 21:29 Brad King, wrote: > On 09/26/2018 12:22 AM, David Gobbi wrote: > > Brad, have there been any new discoveries about why compiler tests > > and custom-command outputs fail to open their output files on Windows > > as described in [cmake issue 12957]? > > That failure was due to not being able to remove or replace the > `.exe` files used for the checks, and it was almost always due to > an antivirus tool locking the files. That's why the fix was to > just use a different `.exe` name each time. Even without an AV > tool, NTFS does not have synchronous delete operations. We could > work around that by renaming a file out of the way before deleting > it, but so far the existing workaround has been sufficient (and the > renaming could also race with AV locks). > > Using a different name isn't an option here, but also this one looks > a bit different because it is about reading a file just after it is > written. Likely the antivirus tool is monitoring all filesystem > operations and opens the file just after creation in order to scan > it. Since the purpose of the check is to avoid letting viruses run > the AV tool likely opens the file without any sharing permissions. > > This kind of AV operation is mostly invisible for humans creating > and reading files, but causes headaches for build systems and other > use cases that do rapid creation and use of files. I think the best > solution is to just exclude one's development directories from the > AV configuration. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 26 07:39:04 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 26 Sep 2018 05:39:04 -0600 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: Hi Dave, If master becomes 8.2, would it be possible for the current release branch to be tagged/released as 8.1.2? The big thing that the release branch has, but that master doesn't, is the old OpenGL backend. I still find the old backend useful for projects that have to run in environments that don't support OpenGL 3.2. - David On Tue, Sep 25, 2018 at 4:16 PM David E DeMarle wrote: > Hey Gang, > > I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. > Does anybody object? > The proposed change can be found at: > https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 > > I want to do this because it will let me make a release now to preserve > what is in master. The larger scale changes we planned for 9.0 will happen > shortly after that. 8.2 will and 9.0 may come out before the end of this > year. > > A topic for future discussion is whether we want to continue the existing, > fairly haphazard naming scheme or move to something better, perhaps a > year.month scheme like several other projects have moved to recently. > > thanks for your advice > > David E DeMarle > Kitware, Inc. > Principal Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Sep 26 09:47:48 2018 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 26 Sep 2018 13:47:48 +0000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: > it is about reading a file just after it is written Reading a file right after it is written is probably one of the most common operations during a build process and it is done successfully by many tools on hundreds of thousands of files. It is odd that only vtkWrapPython runs into problems. Is it possible that the .cxx file that cannot be created (https://public.kitware.com/pipermail/vtk-developers/2018-September/036360.html) existed before and has just been recently deleted? That would explain the problem you are having. ?The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED.? (https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-deletefilea) If anti-virus software has any influence on the build process then most likely then there is some fragile mechanisms in place and the problem likely would occur with any other software that monitors the file system. You cannot possibly identify and disable all these software. Andras From: Andrew Maclean Sent: Wednesday, September 26, 2018 7:34 AM To: Brad King Cc: David Gobbi ; Andras Lasso ; VTK Developers Subject: Re: [vtk-developers] Python Wrapping fails in master build. Thanks for this, I'll see if I can exclude this directory and I'll try it out tomorrow. Andrew Maclean On Wed, 26 Sep. 2018, 21:29 Brad King, > wrote: On 09/26/2018 12:22 AM, David Gobbi wrote: > Brad, have there been any new discoveries about why compiler tests > and custom-command outputs fail to open their output files on Windows > as described in [cmake issue 12957]? That failure was due to not being able to remove or replace the `.exe` files used for the checks, and it was almost always due to an antivirus tool locking the files. That's why the fix was to just use a different `.exe` name each time. Even without an AV tool, NTFS does not have synchronous delete operations. We could work around that by renaming a file out of the way before deleting it, but so far the existing workaround has been sufficient (and the renaming could also race with AV locks). Using a different name isn't an option here, but also this one looks a bit different because it is about reading a file just after it is written. Likely the antivirus tool is monitoring all filesystem operations and opens the file just after creation in order to scan it. Since the purpose of the check is to avoid letting viruses run the AV tool likely opens the file without any sharing permissions. This kind of AV operation is mostly invisible for humans creating and reading files, but causes headaches for build systems and other use cases that do rapid creation and use of files. I think the best solution is to just exclude one's development directories from the AV configuration. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 26 10:00:09 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 26 Sep 2018 08:00:09 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180924112604.GA20321@rotor> <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On Wed, Sep 26, 2018 at 7:47 AM Andras Lasso wrote: > > it is about reading a file just after it is written > > > > Reading a file right after it is written is probably one of the most > common operations during a build process and it is done successfully by > many tools on hundreds of thousands of files. It is odd that only > vtkWrapPython runs into problems. > I don't believe that the problem has anything to do with reading a file just after it is written. Brad, what brought you to that conclusion? The error is that vtkWrapPython sporadically fails to open an output file that already exists. It doesn't seem to have anything to do with how recently it was written. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 26 10:03:21 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 26 Sep 2018 10:03:21 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On 09/26/2018 10:00 AM, David Gobbi wrote: > I don't believe that the problem has anything to do with reading a file > just after it is written.? Brad, what brought you to that conclusion? I misread the thread. > The error is that vtkWrapPython sporadically fails to open an output > file that already exists. It doesn't seem to have anything to do with > how recently it was written. One could instead write to a temporary/random file name and then rename when finished. CMake generates most of its files that way. -Brad From dave.demarle at kitware.com Wed Sep 26 10:13:06 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 26 Sep 2018 10:13:06 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: Thanks for the feedback. I would like to branch in three weeks and rename master later this week. On Wed, Sep 26, 2018 at 2:59 AM Elvis Stansvik wrote: > Den ons 26 sep. 2018 00:16David E DeMarle > skrev: > >> Hey Gang, >> >> I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. >> Does anybody object? >> The proposed change can be found at: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 >> >> I want to do this because it will let me make a release now to preserve >> what is in master. The larger scale changes we planned for 9.0 will happen >> shortly after that. 8.2 will and 9.0 may come out before the end of this >> year. >> > > Sounds good to me. When roughly are you hoping to do the 8.2 release? > Asking because I have this lingering MR that fixes support for fractional > device pixel ratio in the "old"/"native" QVTKOpenGLWidget (the MR predates > the new alien one) that I've been wanting to brush up and get merged, but > work has just kept me swamped so I haven't gotten to it yet. > > MR is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/3973 > > So just wondering whether I have weeks or days to get that done. > > The native QVTKOpenGLWidget is currently broken to the point of being > unusable on fractional (eg 150%) device pixel ratio (for example a > Linux/KDE machine with screen scaling set to 150%). > > >> A topic for future discussion is whether we want to continue the >> existing, fairly haphazard naming scheme or move to something better, >> perhaps a year.month scheme like several other projects have moved to >> recently. >> > > I'm not a dev, but this would be OK with me. We do internal Ubuntu package > builds, and as long as the versioning works well as Ubuntu package > versions, I think it sounds like a good idea (I think Debian supports just > about any versioning scheme, so no worries). > > Elvis > > >> thanks for your advice >> >> David E DeMarle >> Kitware, Inc. >> Principal 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 >> >> 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: >> https://public.kitware.com/mailman/listinfo/vtkusers >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Sep 26 10:14:43 2018 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 26 Sep 2018 10:14:43 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: Sure I can tag and publish 8.1.2 while making 8.2.0.rc1 David E DeMarle Kitware, Inc. Principal Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Sep 26, 2018 at 7:39 AM David Gobbi wrote: > Hi Dave, > > If master becomes 8.2, would it be possible for the current release branch > to be tagged/released as 8.1.2? > > The big thing that the release branch has, but that master doesn't, is the > old OpenGL backend. I still find the old backend useful for projects that > have to run in environments that don't support OpenGL 3.2. > > - David > > > On Tue, Sep 25, 2018 at 4:16 PM David E DeMarle > wrote: > >> Hey Gang, >> >> I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. >> Does anybody object? >> The proposed change can be found at: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/4700 >> >> I want to do this because it will let me make a release now to preserve >> what is in master. The larger scale changes we planned for 9.0 will happen >> shortly after that. 8.2 will and 9.0 may come out before the end of this >> year. >> >> A topic for future discussion is whether we want to continue the >> existing, fairly haphazard naming scheme or move to something better, >> perhaps a year.month scheme like several other projects have moved to >> recently. >> >> thanks for your advice >> >> David E DeMarle >> Kitware, Inc. >> Principal Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Sep 26 10:48:08 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 26 Sep 2018 08:48:08 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On Wed, Sep 26, 2018 at 8:03 AM Brad King wrote: > One could instead write to a temporary/random file name and then > rename when finished. CMake generates most of its files that way. > Thanks for the advice (and for taking the time to read this thread.) This may be the ultimate solution, though I still want to do some digging to see what what magic cl.exe itself uses to avoid this AV interference. For now, though, I'll put together a patch that prints the value of errno when fopen() fails. I'll probably print the result of GetLastError() too, since this is a Windows issue. Hopefully Andrew will be able to see those and report on them. Andras, you used to see similar errors with cmake when it was configuring, so I have to ask, have you seen vtkWrapPython itself fail this way? I'm still trying to get a feel for how widespread this issue is. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Wed Sep 26 10:58:38 2018 From: lasso at queensu.ca (Andras Lasso) Date: Wed, 26 Sep 2018 14:58:38 +0000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: > Andras, you used to see similar errors with cmake when it was configuring, so I have to ask, have you seen vtkWrapPython itself fail this way? I haven?t seen such an issue in the last couple of years. We are building 3D Slicer every night on several computers from scratch. It includes full VTK (few-week-old master) and many VTK-based Python-wrapped classes. We use Windows10, VS2015 (or VS2017 with VS2015 toolset). We use Visual Studio generator, don?t use Ninja. Andras From: David Gobbi Sent: Wednesday, September 26, 2018 10:48 AM To: Brad King Cc: Andras Lasso ; Andrew Maclean ; VTK Developers Subject: Re: [vtk-developers] Python Wrapping fails in master build. On Wed, Sep 26, 2018 at 8:03 AM Brad King > wrote: One could instead write to a temporary/random file name and then rename when finished. CMake generates most of its files that way. Thanks for the advice (and for taking the time to read this thread.) This may be the ultimate solution, though I still want to do some digging to see what what magic cl.exe itself uses to avoid this AV interference. For now, though, I'll put together a patch that prints the value of errno when fopen() fails. I'll probably print the result of GetLastError() too, since this is a Windows issue. Hopefully Andrew will be able to see those and report on them. Andras, you used to see similar errors with cmake when it was configuring, so I have to ask, have you seen vtkWrapPython itself fail this way? I'm still trying to get a feel for how widespread this issue is. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Sep 26 12:23:20 2018 From: DLRdave at aol.com (David Cole) Date: Wed, 26 Sep 2018 12:23:20 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: Is it possible that there might be two custom commands trying to write to the same output file, and it only shows up in ninja because it's better at parallel builds...? Or is it absolutely certain that there's a one-rule/one-output-file correspondence? David C. On Wed, Sep 26, 2018 at 10:58 AM Andras Lasso wrote: > > > Andras, you used to see similar errors with cmake when it was configuring, so I have to ask, have you seen vtkWrapPython itself fail this way? > > > > I haven?t seen such an issue in the last couple of years. > > > > We are building 3D Slicer every night on several computers from scratch. It includes full VTK (few-week-old master) and many VTK-based Python-wrapped classes. We use Windows10, VS2015 (or VS2017 with VS2015 toolset). We use Visual Studio generator, don?t use Ninja. > > > > Andras > > > > From: David Gobbi > Sent: Wednesday, September 26, 2018 10:48 AM > To: Brad King > Cc: Andras Lasso ; Andrew Maclean ; VTK Developers > Subject: Re: [vtk-developers] Python Wrapping fails in master build. > > > > On Wed, Sep 26, 2018 at 8:03 AM Brad King wrote: > > One could instead write to a temporary/random file name and then > rename when finished. CMake generates most of its files that way. > > > > Thanks for the advice (and for taking the time to read this thread.) This may > > be the ultimate solution, though I still want to do some digging to see what > > what magic cl.exe itself uses to avoid this AV interference. > > > > For now, though, I'll put together a patch that prints the value of errno when > > fopen() fails. I'll probably print the result of GetLastError() too, since this is > > a Windows issue. Hopefully Andrew will be able to see those and report on > > them. > > > > Andras, you used to see similar errors with cmake when it was configuring, > > so I have to ask, have you seen vtkWrapPython itself fail this way? I'm still > > trying to get a feel for how widespread this issue is. > > > > - 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > From david.gobbi at gmail.com Wed Sep 26 12:32:37 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 26 Sep 2018 10:32:37 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On Wed, Sep 26, 2018 at 10:23 AM David Cole wrote: > Is it possible that there might be two custom commands trying to write > to the same output file, and it only shows up in ninja because it's > better at parallel builds...? > Andrew already tried a non-parallel build (it was the first thing he tried IIRC) and it made no difference. > Or is it absolutely certain that there's a one-rule/one-output-file > correspondence? > Pretty certain, I think. If there wasn't, then parallel Windows builds would be failing everywhere. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nztoddler at yahoo.com Wed Sep 26 18:33:19 2018 From: nztoddler at yahoo.com (Todd) Date: Thu, 27 Sep 2018 10:33:19 +1200 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Thu Sep 27 05:56:35 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 27 Sep 2018 19:56:35 +1000 Subject: [vtk-developers] Sublime Merge Message-ID: Has anyone looked at this https://www.sublimerge.com I've been using it for the past few days and it is quite good. I generally use the command line or git gui. However if you use Sublime Text, a lot of it is immediately familiar. The 3-way merge is really good. Andrew Maclean -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Thu Sep 27 10:29:07 2018 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 27 Sep 2018 10:29:07 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: Hi Todd, You have a good point, but VTK's current versioning system doesn't guarantee anything about minor/major version changes. Even our "minor" version updates can and do have breaking changes and removed modules. If we followed strict semantic versioning then every release would be a major release. I think the main argument in favor of year.month is that it no longer seems to promise something we don't provide in terms of compatibility. Shawn On Wed, Sep 26, 2018 at 6:33 PM, Todd via vtk-developers < vtk-developers at public.kitware.com> wrote: > I have no objection, but I have to ask "What does the major version number > change mean? Does it signify breaking changes or the addition of > new/removal of old modules?" > > In regards to some of the other feedback; the problem with month.year > versioning is that it represents nothing more than chronology. How would > new/deprecated features be signalled? > > On 27 Sep 2018 2:13 a.m., David E DeMarle > wrote: > > Thanks for the feedback. I would like to branch in three weeks and rename > master later this week. > > On Wed, Sep 26, 2018 at 2:59 AM Elvis Stansvik < > elvis.stansvik at orexplore.com> wrote: > > Den ons 26 sep. 2018 00:16David E DeMarle > skrev: > > Hey Gang, > > I'd like to change the VTK version number in master from 9.0.0 to 8.2.0. > Does anybody object? > The proposed change can be found at: https://gitlab.kitware.com/ > vtk/vtk/merge_requests/4700 > > I want to do this because it will let me make a release now to preserve > what is in master. The larger scale changes we planned for 9.0 will happen > shortly after that. 8.2 will and 9.0 may come out before the end of this > year. > > > Sounds good to me. When roughly are you hoping to do the 8.2 release? > Asking because I have this lingering MR that fixes support for fractional > device pixel ratio in the "old"/"native" QVTKOpenGLWidget (the MR predates > the new alien one) that I've been wanting to brush up and get merged, but > work has just kept me swamped so I haven't gotten to it yet. > > MR is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/3973 > > So just wondering whether I have weeks or days to get that done. > > The native QVTKOpenGLWidget is currently broken to the point of being > unusable on fractional (eg 150%) device pixel ratio (for example a > Linux/KDE machine with screen scaling set to 150%). > > > A topic for future discussion is whether we want to continue the existing, > fairly haphazard naming scheme or move to something better, perhaps a > year.month scheme like several other projects have moved to recently. > > > I'm not a dev, but this would be OK with me. We do internal Ubuntu package > builds, and as long as the versioning works well as Ubuntu package > versions, I think it sounds like a good idea (I think Debian supports just > about any versioning scheme, so no worries). > > Elvis > > > thanks for your advice > > David E DeMarle > Kitware, Inc. > Principal 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 > > 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: > https://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: > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Thu Sep 27 10:39:27 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Thu, 27 Sep 2018 10:39:27 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: Message-ID: <20180927143927.GA22820@rotor.kitware.com> On Thu, Sep 27, 2018 at 10:33:19 +1200, Todd via vtk-developers wrote: > I have no objection, but I have to ask "What does the major version number > change mean? Does it signify breaking changes or the addition of new/removal of > old modules?" Even minor bumps could have added or removed modules. Major version bumps in the past have been gut feeling based on how much has changed since the last release (e.g., OpenGL2 backend, pipeline reworking, modularization). > In regards to some of the other feedback; the problem with month.year > versioning is that it represents nothing more than chronology. How would new/ > deprecated features be signalled? Release notes. For VTK, even 8.1 to 8.2 meant some code likely had to change, so even minor bumps have not been indicative of "just recompile" upgrades. --Ben From bill.lorensen at gmail.com Thu Sep 27 23:15:17 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 27 Sep 2018 20:15:17 -0700 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: <20180927143927.GA22820@rotor.kitware.com> References: <20180927143927.GA22820@rotor.kitware.com> Message-ID: I'd like to see a BUILD_NUMBER encoded in the version. On Thu, Sep 27, 2018 at 7:39 AM Ben Boeckel wrote: > > On Thu, Sep 27, 2018 at 10:33:19 +1200, Todd via vtk-developers wrote: > > I have no objection, but I have to ask "What does the major version number > > change mean? Does it signify breaking changes or the addition of new/removal of > > old modules?" > > Even minor bumps could have added or removed modules. Major version > bumps in the past have been gut feeling based on how much has changed > since the last release (e.g., OpenGL2 backend, pipeline reworking, > modularization). > > > In regards to some of the other feedback; the problem with month.year > > versioning is that it represents nothing more than chronology. How would new/ > > deprecated features be signalled? > > Release notes. For VTK, even 8.1 to 8.2 meant some code likely had to > change, so even minor bumps have not been indicative of "just recompile" > upgrades. > > --Ben > _______________________________________________ > 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: > https://public.kitware.com/mailman/listinfo/vtkusers -- Unpaid intern in BillsParadise at noware dot com From david.gobbi at gmail.com Thu Sep 27 23:28:32 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 27 Sep 2018 21:28:32 -0600 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: <20180927143927.GA22820@rotor.kitware.com> Message-ID: On Thu, Sep 27, 2018 at 9:15 PM Bill Lorensen wrote: > I'd like to see a BUILD_NUMBER encoded in the version. > You mean a number that changes each time VTK is built? The download page already has an MD5 hash for each package, which serves the same purpose, unless I'm misunderstanding. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Sep 27 23:44:22 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 27 Sep 2018 20:44:22 -0700 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: <20180927143927.GA22820@rotor.kitware.com> Message-ID: I mean a # that increments nightly. Resets to 0 when a the revision number changes. Major.Minor.Patch.Build Right now if a new class is added you there is no way to know from the version when it was added. I think we used to do this in vtk... Back in April 2008 a nightly build increment was stopped Bill On Thu, Sep 27, 2018 at 8:28 PM David Gobbi wrote: > > On Thu, Sep 27, 2018 at 9:15 PM Bill Lorensen wrote: >> >> I'd like to see a BUILD_NUMBER encoded in the version. > > > You mean a number that changes each time VTK is built? > The download page already has an MD5 hash for each package, > which serves the same purpose, unless I'm misunderstanding. > > - David -- Unpaid intern in BillsParadise at noware dot com From andrew.amaclean at gmail.com Fri Sep 28 00:14:06 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 28 Sep 2018 14:14:06 +1000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: Just did a build and I have one failure: [381/4832] Python Wrapping - generating vtkRungeKutta2Python.cxx FAILED: Wrapping/Python/vtkRungeKutta2Python.cxx cmd.exe /C "cd /D C:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && C:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe @C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args -o C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx C:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkRungeKutta2.h" Error 13 opening output file C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx: Permission denied On Thu, Sep 27, 2018 at 2:23 AM David Cole wrote: > Is it possible that there might be two custom commands trying to write > to the same output file, and it only shows up in ninja because it's > better at parallel builds...? > > Or is it absolutely certain that there's a one-rule/one-output-file > correspondence? > > > David C. > On Wed, Sep 26, 2018 at 10:58 AM Andras Lasso wrote: > > > > > Andras, you used to see similar errors with cmake when it was > configuring, so I have to ask, have you seen vtkWrapPython itself fail this > way? > > > > > > > > I haven?t seen such an issue in the last couple of years. > > > > > > > > We are building 3D Slicer every night on several computers from scratch. > It includes full VTK (few-week-old master) and many VTK-based > Python-wrapped classes. We use Windows10, VS2015 (or VS2017 with VS2015 > toolset). We use Visual Studio generator, don?t use Ninja. > > > > > > > > Andras > > > > > > > > From: David Gobbi > > Sent: Wednesday, September 26, 2018 10:48 AM > > To: Brad King > > Cc: Andras Lasso ; Andrew Maclean < > andrew.amaclean at gmail.com>; VTK Developers > > Subject: Re: [vtk-developers] Python Wrapping fails in master build. > > > > > > > > On Wed, Sep 26, 2018 at 8:03 AM Brad King wrote: > > > > One could instead write to a temporary/random file name and then > > rename when finished. CMake generates most of its files that way. > > > > > > > > Thanks for the advice (and for taking the time to read this thread.) > This may > > > > be the ultimate solution, though I still want to do some digging to see > what > > > > what magic cl.exe itself uses to avoid this AV interference. > > > > > > > > For now, though, I'll put together a patch that prints the value of > errno when > > > > fopen() fails. I'll probably print the result of GetLastError() too, > since this is > > > > a Windows issue. Hopefully Andrew will be able to see those and report > on > > > > them. > > > > > > > > Andras, you used to see similar errors with cmake when it was > configuring, > > > > so I have to ask, have you seen vtkWrapPython itself fail this way? I'm > still > > > > trying to get a feel for how widespread this issue is. > > > > > > > > - 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: > > https://public.kitware.com/mailman/listinfo/vtk-developers > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 28 01:02:59 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 27 Sep 2018 23:02:59 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: Thanks, Andrew. So now we know that errno is EACCES, which corresponds to a Windows filesystem error of ERROR_ACCESS_DENIED or ERROR_SHARING_VIOLATION. I strongly suspect the latter. So there are two options: 1) retry a few times (e.g. 5 times over 5 seconds), in the hope that the sharing violation will clear up, which it probably will because antivirus software only takes a fraction of a second to scan a small file. 2) write to a temporary file which is then renamed to ..Python.cxx (in which case the 'rename' operation has to retry if it encounters a sharing violation). The latter is what CMake does (its "cmSystemTools::RenameFile()" function retries, so cmake doesn't seem to have any magic that makes retries unnecessary). I'm tempted to go with (1) due to its simplicity, and because if we used a random temporary file we'd have to find some way to remove that file if vtkWrapPython didn't exit cleanly. - David On Thu, Sep 27, 2018 at 10:14 PM Andrew Maclean wrote: > Just did a build and I have one failure: > [381/4832] Python Wrapping - generating vtkRungeKutta2Python.cxx > FAILED: Wrapping/Python/vtkRungeKutta2Python.cxx > cmd.exe /C "cd /D > C:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && > C:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe > @C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args > -o > C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx > C:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkRungeKutta2.h" > Error 13 opening output file > C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx: > Permission denied > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Sep 28 09:05:55 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 28 Sep 2018 09:05:55 -0400 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: References: <20180927143927.GA22820@rotor.kitware.com> Message-ID: <20180928130555.GA7447@rotor.kitware.com> On Thu, Sep 27, 2018 at 20:44:22 -0700, Bill Lorensen wrote: > I mean a # that increments nightly. Resets to 0 when a the revision > number changes. > > Major.Minor.Patch.Build > > Right now if a new class is added you there is no way to know from the > version when it was added. > > I think we used to do this in vtk... CMake does this, but it is not just a number that resets to 0, but a datestamp: https://gitlab.kitware.com/cmake/cmake/commit/8bb0e09e38d3ab75198b1cd9746bfa7a7b80ff94 It is used *as* the patch number, not a fourth component. This means that as soon as we branch and make M.N.0, `master` is already M.N.2018MMDD and "bigger". --Ben From bill.lorensen at gmail.com Fri Sep 28 09:27:18 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 28 Sep 2018 06:27:18 -0700 Subject: [vtk-developers] [vtkusers] Discussion: OK to change VTK's version number from 9.0 to 8.2? In-Reply-To: <20180928130555.GA7447@rotor.kitware.com> References: <20180927143927.GA22820@rotor.kitware.com> <20180928130555.GA7447@rotor.kitware.com> Message-ID: That would work. On Fri, Sep 28, 2018, 6:05 AM Ben Boeckel wrote: > On Thu, Sep 27, 2018 at 20:44:22 -0700, Bill Lorensen wrote: > > I mean a # that increments nightly. Resets to 0 when a the revision > > number changes. > > > > Major.Minor.Patch.Build > > > > Right now if a new class is added you there is no way to know from the > > version when it was added. > > > > I think we used to do this in vtk... > > CMake does this, but it is not just a number that resets to 0, but a > datestamp: > > > https://gitlab.kitware.com/cmake/cmake/commit/8bb0e09e38d3ab75198b1cd9746bfa7a7b80ff94 > > It is used *as* the patch number, not a fourth component. This means > that as soon as we branch and make M.N.0, `master` is already > M.N.2018MMDD and "bigger". > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 28 10:32:29 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 28 Sep 2018 08:32:29 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On Thu, Sep 27, 2018 at 11:02 PM David Gobbi wrote: > Thanks, Andrew. So now we know that errno is EACCES, which corresponds to > a Windows filesystem error of ERROR_ACCESS_DENIED > or ERROR_SHARING_VIOLATION. I strongly suspect the latter. > > So there are two options: > > 1) retry a few times (e.g. 5 times over 5 seconds), in the hope that the > sharing violation will clear up, which it probably will because antivirus > software only takes a fraction of a second to scan a small file. > > 2) write to a temporary file which is then renamed to ..Python.cxx (in > which case the 'rename' operation has to retry if it encounters a sharing > violation). > > The latter is what CMake does (its "cmSystemTools::RenameFile()" function > retries, so cmake doesn't seem to have any magic that makes retries > unnecessary). > > I'm tempted to go with (1) due to its simplicity, and because if we used a > random temporary file we'd have to find some way to remove that file if > vtkWrapPython didn't exit cleanly. > Another option that might work: 3) If the output file already exists, then delete it with the Windows DeleteFile() function before calling fopen() to create a new file with the same name. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Sep 28 11:01:22 2018 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 28 Sep 2018 09:01:22 -0600 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: On Fri, Sep 28, 2018 at 8:32 AM David Gobbi wrote: > On Thu, Sep 27, 2018 at 11:02 PM David Gobbi > wrote: > >> Thanks, Andrew. So now we know that errno is EACCES, which corresponds >> to a Windows filesystem error of ERROR_ACCESS_DENIED >> or ERROR_SHARING_VIOLATION. I strongly suspect the latter. >> >> So there are two options: >> >> 1) retry a few times (e.g. 5 times over 5 seconds), in the hope that the >> sharing violation will clear up, which it probably will because antivirus >> software only takes a fraction of a second to scan a small file. >> >> 2) write to a temporary file which is then renamed to ..Python.cxx (in >> which case the 'rename' operation has to retry if it encounters a sharing >> violation). >> >> The latter is what CMake does (its "cmSystemTools::RenameFile()" function >> retries, so cmake doesn't seem to have any magic that makes retries >> unnecessary). >> >> I'm tempted to go with (1) due to its simplicity, and because if we used >> a random temporary file we'd have to find some way to remove that file if >> vtkWrapPython didn't exit cleanly. >> > > Another option that might work: > > 3) If the output file already exists, then delete it with the Windows > DeleteFile() function before calling fopen() to create a new file with the > same name. > Or, if the above doesn't work, the following closely related trick might work: 4) If the output file already exists, then rename it with MoveFile() and delete the renamed file. It should then be possible to call fopen() with the proper name. The hypothesis is that MoveFile() won't cause a sharing violation because it has no impact on existing file handles. This is just a hypothesis, though, and my conceptions of how files should work is biased strongly towards UNIX-like behavior. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Sep 28 15:20:54 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 28 Sep 2018 15:20:54 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: Message-ID: <20180928192054.GA9902@rotor.kitware.com> On Fri, Sep 28, 2018 at 09:01:22 -0600, David Gobbi wrote: > 4) If the output file already exists, then rename it with MoveFile() and > delete the renamed file. It should then be possible to call fopen() with > the proper name. > > The hypothesis is that MoveFile() won't cause a sharing violation because > it has no impact on existing file handles. This is just a hypothesis, > though, and my conceptions of how files should work is biased strongly > towards UNIX-like behavior. Nope, that's a UNIX-ism :) . Moving a file is locked down just like deleting an open file is locked down on Windows. UNIX has always had the "file with this path isn't *the* file" because of hard links and as such allowed removing deleted files since the name wasn't the thing actually keeping it alive (that'd be the inode). --Ben From isaiah.norton at gmail.com Fri Sep 28 16:28:19 2018 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Fri, 28 Sep 2018 16:28:19 -0400 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> Message-ID: FWIW, I've debugged similar issues in the past by using Process Explorer [1]. You can search for the file name with 'Find' menu -> 'Find handle or DLL', enter filename, then see which process(es) are holding it. [1] https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer - On Fri, Sep 28, 2018 at 12:14 AM Andrew Maclean wrote: > Just did a build and I have one failure: > [381/4832] Python Wrapping - generating vtkRungeKutta2Python.cxx > FAILED: Wrapping/Python/vtkRungeKutta2Python.cxx > cmd.exe /C "cd /D > C:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && > C:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe > @C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args > -o > C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx > C:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkRungeKutta2.h" > Error 13 opening output file > C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx: > Permission denied > > > > > On Thu, Sep 27, 2018 at 2:23 AM David Cole wrote: > >> Is it possible that there might be two custom commands trying to write >> to the same output file, and it only shows up in ninja because it's >> better at parallel builds...? >> >> Or is it absolutely certain that there's a one-rule/one-output-file >> correspondence? >> >> >> David C. >> On Wed, Sep 26, 2018 at 10:58 AM Andras Lasso wrote: >> > >> > > Andras, you used to see similar errors with cmake when it was >> configuring, so I have to ask, have you seen vtkWrapPython itself fail this >> way? >> > >> > >> > >> > I haven?t seen such an issue in the last couple of years. >> > >> > >> > >> > We are building 3D Slicer every night on several computers from >> scratch. It includes full VTK (few-week-old master) and many VTK-based >> Python-wrapped classes. We use Windows10, VS2015 (or VS2017 with VS2015 >> toolset). We use Visual Studio generator, don?t use Ninja. >> > >> > >> > >> > Andras >> > >> > >> > >> > From: David Gobbi >> > Sent: Wednesday, September 26, 2018 10:48 AM >> > To: Brad King >> > Cc: Andras Lasso ; Andrew Maclean < >> andrew.amaclean at gmail.com>; VTK Developers >> > Subject: Re: [vtk-developers] Python Wrapping fails in master build. >> > >> > >> > >> > On Wed, Sep 26, 2018 at 8:03 AM Brad King >> wrote: >> > >> > One could instead write to a temporary/random file name and then >> > rename when finished. CMake generates most of its files that way. >> > >> > >> > >> > Thanks for the advice (and for taking the time to read this thread.) >> This may >> > >> > be the ultimate solution, though I still want to do some digging to see >> what >> > >> > what magic cl.exe itself uses to avoid this AV interference. >> > >> > >> > >> > For now, though, I'll put together a patch that prints the value of >> errno when >> > >> > fopen() fails. I'll probably print the result of GetLastError() too, >> since this is >> > >> > a Windows issue. Hopefully Andrew will be able to see those and report >> on >> > >> > them. >> > >> > >> > >> > Andras, you used to see similar errors with cmake when it was >> configuring, >> > >> > so I have to ask, have you seen vtkWrapPython itself fail this way? >> I'm still >> > >> > trying to get a feel for how widespread this issue is. >> > >> > >> > >> > - 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: >> > https://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > https://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lasso at queensu.ca Fri Sep 28 17:08:57 2018 From: lasso at queensu.ca (Andras Lasso) Date: Fri, 28 Sep 2018 21:08:57 +0000 Subject: [vtk-developers] Python Wrapping fails in master build. In-Reply-To: References: <20180925121837.GA1229@rotor> <20180925202143.GA9821@rotor.kitware.com> <8da35a37-3546-76df-f3bf-278c2719de54@kitware.com> , Message-ID: <236679eb-3c7d-416b-ba42-1d6c2a25b0d9@queensu.ca> Process and explorer only shows current locks, and this seems to be a quick, transient state. If you are curious which process caused the conflict, you can use Process monitor tool, which can log all access from all processes to all files. It is not that relevant though which process is that, because there is countless applications that legitimately lock files for short time periods. Andras ________________________________ From: Isaiah Norton Sent: Friday, September 28, 2018 4:28 PM To: andrew.amaclean at gmail.com Cc: vtkdev; David Gobbi; Brad King Subject: Re: [vtk-developers] Python Wrapping fails in master build. FWIW, I've debugged similar issues in the past by using Process Explorer [1]. You can search for the file name with 'Find' menu -> 'Find handle or DLL', enter filename, then see which process(es) are holding it. [1] https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer - On Fri, Sep 28, 2018 at 12:14 AM Andrew Maclean > wrote: Just did a build and I have one failure: [381/4832] Python Wrapping - generating vtkRungeKutta2Python.cxx FAILED: Wrapping/Python/vtkRungeKutta2Python.cxx cmd.exe /C "cd /D C:\Users\amaclean\Development\Kitware\build\VTK-Release\Wrapping\Python && C:\Users\amaclean\Development\Kitware\build\VTK-Release\bin\vtkWrapPython-9.0.exe @C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkCommonMathPython.Release.args -o C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx C:/Users/amaclean/Development/Kitware/src/VTK/Common/Math/vtkRungeKutta2.h" Error 13 opening output file C:/Users/amaclean/Development/Kitware/build/VTK-Release/Wrapping/Python/vtkRungeKutta2Python.cxx: Permission denied On Thu, Sep 27, 2018 at 2:23 AM David Cole > wrote: Is it possible that there might be two custom commands trying to write to the same output file, and it only shows up in ninja because it's better at parallel builds...? Or is it absolutely certain that there's a one-rule/one-output-file correspondence? David C. On Wed, Sep 26, 2018 at 10:58 AM Andras Lasso > wrote: > > > Andras, you used to see similar errors with cmake when it was configuring, so I have to ask, have you seen vtkWrapPython itself fail this way? > > > > I haven?t seen such an issue in the last couple of years. > > > > We are building 3D Slicer every night on several computers from scratch. It includes full VTK (few-week-old master) and many VTK-based Python-wrapped classes. We use Windows10, VS2015 (or VS2017 with VS2015 toolset). We use Visual Studio generator, don?t use Ninja. > > > > Andras > > > > From: David Gobbi > > Sent: Wednesday, September 26, 2018 10:48 AM > To: Brad King > > Cc: Andras Lasso >; Andrew Maclean >; VTK Developers > > Subject: Re: [vtk-developers] Python Wrapping fails in master build. > > > > On Wed, Sep 26, 2018 at 8:03 AM Brad King > wrote: > > One could instead write to a temporary/random file name and then > rename when finished. CMake generates most of its files that way. > > > > Thanks for the advice (and for taking the time to read this thread.) This may > > be the ultimate solution, though I still want to do some digging to see what > > what magic cl.exe itself uses to avoid this AV interference. > > > > For now, though, I'll put together a patch that prints the value of errno when > > fopen() fails. I'll probably print the result of GetLastError() too, since this is > > a Windows issue. Hopefully Andrew will be able to see those and report on > > them. > > > > Andras, you used to see similar errors with cmake when it was configuring, > > so I have to ask, have you seen vtkWrapPython itself fail this way? I'm still > > trying to get a feel for how widespread this issue is. > > > > - 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: > https://public.kitware.com/mailman/listinfo/vtk-developers > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: https://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: