[vtk-developers] Rudimentary testing of vtkpython [long].

Blezek, Daniel J (CRD) blezek at crd.ge.com
Fri Sep 21 11:49:46 EDT 2001


Prabhu,

  I think this is a great way to go!  Since VTK 4.0 has broken most if not all ties with 3.2, you
should go ahead and add the code in.  Since Jim Miller and I have started doing much of our work in
Python, I've been very impressed with the language, and would like to see vtk's Python support
enhanced.  I also put forth the suggestion that we use "import vtk" rather than "vtkpython".  It's
very trivial to support backward's compatability with "vtkpython", I just need consensus to make the
changes.  If you are willing, I would also ask you to add the vtkPipeline browser stuff more
available.  Perhaps Kitware would host some sort of VTK "Add-on's" from their site, rather than
having to search all over creation to collect useful code.

  Frankly, I think this sort of testing is long overdue, and will likely catch many "lazy" developer
errors.  I know that Bill Lorensen has a Tcl script that calls Update() on each filter with no input
set, and the results are quite disappointing.  These bugs can be very hard to track down when the
code crashes on you immediately.

Just $0.02,
-dan

-----Original Message-----
From: Prabhu Ramachandran [mailto:prabhu at aero.iitm.ernet.in]
Sent: Friday, September 21, 2001 11:36 AM
To: vtk-developers at public.kitware.com
Subject: RE: [vtk-developers] Rudimentary testing of vtkpython [long].


hi,

>>>>> "Bill" == William E Lorensen <Lorensen> writes:

    Bill> Prabhu, This sort of black box testing is great! We do some
    Bill> now, but not enough. We need to figure out how to roll this
    Bill> into the nightly testing. Perhaps you could do a submit from
    Bill> your location.

Glad to know you are interested in this.  First let me tell you what
the parser does now.

  (1) Given a vtk object it figures out the following:

      (a) Find all the methods that are created using the BooleanMacro
      i.e. all the XYZOn/Off kind of methods.

      (b) Find all the methods that are of the SetXXXToYYY form and
      tie them all together - so you can use a radiobox.

      (c) Find all the GetXXX/SetXXX methods that have values that are
      floats/ints/strings/tuples that are possibly editable via a gui.
      This eliminates all methods that Get/Set another vtk object.

      (d) Find all the pure Get methods - like GetBounds() or
      GetXXXAsString().

  In order to do the above it has to access every single method and
  figure out the methods so just determining these methods is itself a
  somewhat comprehensive test of a single VTK object in isolation.

  (2) Since this is a generic tool that all sorts of users and
  applications use I need to throw in backward compatibility etc.  In
  December 2000 David added some cool features to the python wrappers
  making it very easy to get the methods of a vtk object etc.  My
  current code has to work for those who still use an old release.

  (3) There are also a lot of bugs, some that caused Segfaults to
  occur or other problems like the infinite loop case with the
  DataReaders infinite loops that I managed to fix.  I have to trap
  these too and ensure my app doesnt crash!  So there are lots of
  silly checks in the code currently that allow me to handle this
  properly.

There are several issues and questions about the testing itself:

  (0) For now I'll aim for simple, fast tests - no dumping images and
  doing ImageDiffs etc.  I like the continuous build page that shows
  how each cvs commit affects the build.  It would be nice if we could
  add a 2 minute test that would atleast test if the python wrappers
  are useable.  Something like last night's problem with the
  vtkFieldDataToAttributeDataFilter problem would have been detected
  immediately.

  (1) What exactly are you looking for in the tests?  Here is a list
  that I would think useful:
  
      (a) Check if we can import vtkpython. Trivial.

      (b) Check if we can instantiate the 500+ classes - again
      trivial.

      (c) Check if we can parse the vtk object as done above.  This
      usually detects all the segfault problems. 

      (d) Do a val = GetXXX(), followed by a SetXXX(val) and check if
      the next GetXXX() is the same.

      (e) For boolean vars do an On and see if the value is 1?  I
      dont know if this is necessary since it is all done anyway by a
      macro.

      (f) Check if the clamping is working okay by using the
      MinValue/MaxValue methods.  Again may not make sense wasting
      time on this?

      (g) Checking for incorrect obsolete messages?

  (2) What kind of output do you want?  I can combine a the python
  code with a shell script that checks for segfaults and automatically
  identifies all the bad classes.  Or even have a driver python
  program BTW are you folks interested in fixing the Segfault problems
  or are they a waste of time?

  (3) The incomplete obsolete messages can be done by searching for
  patterns in the error logs.

  (4) Do you want me to check if the PrintSelf is also okay?  I can
  print the object and see if all variables are covered?


For one thing I will remove all the silly checks in the current code
and check aggressively for bugs and wont try to work around them.
Also, I will only make it work with the latest tree.  So at any point
it will work with the current CVS tree.  Getting it to work with older
releases is a pain.

Let me know what you think and need.

thanks,
prabhu
_______________________________________________
vtk-developers mailing list
vtk-developers at public.kitware.com
http://public.kitware.com/mailman/listinfo/vtk-developers



More information about the vtk-developers mailing list