[vtk-developers] GetOutput().GetWholeExtent()

[Berk Geveci]

Thank you David.

I have been working on a set of documents to help migration to VTK 6. One
thing that I noticed while working on these is that the way we access this
sort of meta-data is fairly inconsistent. There are some convenience
functions in vtkDataObject, vtkStreamingDemandDrivenPipeline etc. to
set/get meta-data and some of them are accessed directly. I am too burned
out to tackle this right now but it is something to think about...

-berk

On Wed, Mar 28, 2012 at 7:25 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Adding a hint for Get(vtkInformationIntegerVectorKey *) turned out to
> be straightforward.. I have a patch in gerrit that allows Get to be used
> with all IntegerVector and DoubleVector keys so that WHOLE_EXTENT,
> SPACING, ORIGIN, etc. can be used from the wrappers.  I'll probably
> merge tomorrow.
>
> A more general solution, i.e. one that also encompasses IntegerPointer
> keys (yikes!) will have to wait...
>
>  - david
>
>
>
> On Wed, Mar 28, 2012 at 3:46 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > You mean a generic "pointer" object that can be used from Python.
> >
> > In Python 3, there is a special object called "memoryview" that can be
> > used for this purpose, so that's the direction that I've considered
> > going.  I'd like to avoid generic pointer wrapping, because it makes
> > it too easy to crash the program from python.  I know that SWIG wraps
> > pointers, but I've made a conscious choice not to do the same for the
> > VTK wrappers.
> >
> >  - David
> >
> >
> > On Wed, Mar 28, 2012 at 3:32 PM, Pat Marion <pat.marion at kitware.com>
> wrote:
> >> Hi David,
> >>
> >> What about making a generic way to access these kinds of arrays, given a
> >> length argument, using ctypes or numpy?
> >>
> >> Something like:
> >>
> >> length = info.Length(key)
> >> myarray = vtk.array_from_pointer(info.Get(key), length)
> >>
> >>
> >> Pat
> >>
> >>
> >> On Wed, Mar 28, 2012 at 4:08 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>>
> >>> Hmm, I just noticed something in my own code.  The following method
> >>> isn't wrapped, because it returns a bare pointer.  As a result the
> >>> WHOLE_EXTENT key can't be used with Get:
> >>>
> >>> int * vtkInformation::Get(vtkInformationIntegerVectorKey *);
> >>>
> >>> But I think that I can add a wrapper hint to get it working... the
> >>> wrappers can internally query the Length() method to figure out what
> >>> number of values to return.
> >>>
> >>>  - David
> >>>
> >>>
> >>> On Fri, Mar 23, 2012 at 10:44 AM, Philippe Pebay
> >>> <philippe.pebay at kitware.com> wrote:
> >>> > Thanks Bill.
> >>> >
> >>> > Philippe
> >>> >
> >>> >
> >>> > On Fri, Mar 23, 2012 at 4:49 PM, Bill Lorensen <
> bill.lorensen at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> This page has a suggested replacement.
> >>> >> http://vtk.org/Wiki/VTK/VTK6/Migration/WikiExamples#Improve
> >>> >>
> >>> >> On Fri, Mar 23, 2012 at 8:23 AM, Philippe Pebay
> >>> >> <philippe.pebay at kitware.com> wrote:
> >>> >> > Hello all
> >>> >> >
> >>> >> > GetOutput().GetWholeExtent() does not work any longer in VTK 6. I
> >>> >> > have q
> >>> >> > boatload of vtkpython scripts using this! Does anyone know what
> the
> >>> >> > quick
> >>> >> > fix is?
> >>> >> >
> >>> >> > Thanks
> >>> >> > Philippe
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>
> >>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20120404/f2b8c533/attachment.htm>