[vtk-developers] IRC log for 21 May 2002.

Prabhu Ramachandran prabhu at aero.iitm.ernet.in
Tue May 21 11:08:06 EDT 2002


Attached is today's IRC session log.


<burp>          howdy prabhu!
<prabhu>        fine.
<legoandy>      Hi Prabhu
<prabhu>        hi andy!
<legoandy>      I finally got VTK/Python work on Sun with Sun's C++
<prabhu>        oh, what was the problem?
<prabhu>        special linker flags?
<legoandy>      The trick is you have to link -lC -lCrun and -lCstd
<prabhu>        cool.
<legoandy>      Otherwise you do not have C++ symbols and does not work
<prabhu>        Is this now part of VTK? i.e. is it automagically done 
if compiler==sun?
<legoandy>      So, I guess there will be the three of us today.
<prabhu>        its still early.
<legoandy>      I don't think it should be automatically because this may 
not be the right solution
<legoandy>      or maybe we should wait until CMake does TRY_RUN
<prabhu>        oh ok.
<prabhu>        whats that?
<prabhu>        I'm not too good with Cmake.
<legoandy>      Then we can try to compile something and see what happens 
during compile time
<legoandy>      Do you know autoconf?
<prabhu>        not too well again
<legoandy>      Well, it is the notion of trying to run/compile something during  cmake stage 
<prabhu>        I can hack through it
<prabhu>        ok
<legoandy>      before make takes over
<prabhu>        ok I get it.
<prabhu>        Andy, are you sure no one else will be coming in today?
<legoandy>      I was kidding...
<prabhu>        ok. :)
<prabhu>        BTW about the vtk-python-test code.
<legoandy>      Though, it is close to 10
<prabhu>        any opinions? Or should I wait for the test expert, i.e. Bill to get in?
-->     VTK850 (~vtk850 at dutidad.twi.tudelft.nl) has joined #vtk
-->     _amy_ (~AMY at tripoint.kitware.com) has joined #vtk
<prabhu>        hi all!
---     VTK850 is now known as Bigguy
-->     berk (~berk at tripoint.kitware.com) has joined #vtk
<Bigguy>        hi
-->     KenMartin (~kenmartin at cm-24-29-63-110.nycap.rr.com) has joined #vtk
<Bigguy>        congrats Ken!
<prabhu>        wow, ten sharp, eh?
<KenMartin>     Thanks Bill
<legoandy>      Hello all
<Bigguy>        and Michelle
<prabhu>        congrats?
<KenMartin>     I did all the work :-)
<KenMartin>     We just had a baby girl
<prabhu>        Wow! Congratulations!
<burp>  KenMartin: Congratulations!
---     burp is now known as cpbotha
<KenMartin>     I guess we should get started. 
<prabhu>        Yes.
<legoandy>      I guess she is the youngest VTK developer
<prabhu>        :)
<prabhu>        or the latest VTK development? ;)
<KenMartin>     One item I have is to check and see if any cares if we remove vtkPointLocator2d and vtkMergePoints2d
<prabhu>        I'd like clarifications on the vtk-python test code before I commit.
<KenMartin>     Andy sent out an email last week. Both classes have low coverage and there is at least one bug in PointLocator2D
<legoandy>      Major bug...
<legoandy>      (Does not work at all)
<Bigguy>        I'm checking now...
<Bigguy>        We're not using it
<KenMartin>     Basically they are 2d versions of the regular pointlocator and mergepoints. Nice to have but if we are not using them... 
<KenMartin>     Any objections to deprecating them and then removing them ...
<KenMartin>     going
<prabhu>        I have no objections but I'm probably the worst person to ask.
<KenMartin>     going
<KenMartin>     gone
<legoandy>      Right on!
<KenMartin>     I'll deprecate them and then in a month or two remove them
<prabhu>        I have a few questions.
<KenMartin>     OK
<prabhu>        1. do you folks use the vtk-python code and test it out regularly?
<prabhu>        2. any suggestions for the vtk-python black box test code
<legoandy>      (I don't think so... At least not on Sun)
<prabhu>        or do I simply commit it and let the comments flow?
<KenMartin>     At Kitware we do not really use python with VTK, we do run the python tests in VTK on some nightly machine
<Bigguy>        we use it at GE
<prabhu>        ok.
<Bigguy>        not me though
<Bigguy>        dan and jimbo
<prabhu>        so it would help if I did commit some simple test code for the python stuff?
<prabhu>        Its been long in wait here.
<prabhu>        Can I just go ahead and commit into Wrapping/Python/tests
<prabhu>        and then let it evolve from there?
<Bigguy>        try an experimental
<KenMartin>     It would help as long as the tests pass :-) 
<prabhu>        :)
<KenMartin>     If the tests fail all over the place then we cannot just add them to VTK
<KenMartin>     We would need to slowly introduce them and fix as we go
<prabhu>        Actually a few classes segfault and I check to ensure that they arent used.
<prabhu>        Well, I wont make it part of the test procedure.
<prabhu>        I'll just stick them in and from then we could slowly add them in?
<KenMartin>     What do you mean, not part of the test procedure?
<prabhu>        i.e. it wont be run each night.
<Bigguy>        why not get thinks going with an experimenntal build?
<prabhu>        once we are sure that I'm not goofing and I get the hang of it we can "regularize" it.
<Bigguy>        ken had a great suggestion a while back
<Bigguy>        e should not add new machines until they get fairly green on the experimenalt
<prabhu>        What is needed to do an experimental build?
<Bigguy>        dart
<legoandy>      (and VTKData)
<prabhu>        and I'd have to run it nightly?
<Bigguy>        there are instructions on the datr page
<prabhu>        ok
<Bigguy>        you can run it whenever you want
<prabhu>        ok.
<Bigguy>        it will be rolled into the "current" dartboard
<prabhu>        I guess I'll do some reading on that before asking anymore.
<Bigguy>        how about the Examples
<prabhu>        you mean Python examples?
<KenMartin>     If you think your tests will pass, then do an experimental (or run ctest) to make sure, then check it in
<KenMartin>     my concern...
<Bigguy>        shouldn't we have at least one site testing them?
<KenMartin>     was that the test you wrote would fail
<Bigguy>        I'll bet a beer that some of them don't work anymore.
<prabhu>        KenMartin: Ok.
<prabhu>        KenMartin: The deal is there are several tests that did fail and even segfaulted.
<KenMartin>     I just want to avoid adding a bunch of errors to the dashboard with the hope that they will be fixed
<prabhu>        I posted about it and no one responded.
<prabhu>        ok
<prabhu>        I understand
<KenMartin>     Several existing tests or several of the new block box tests?
<prabhu>        which is why I will just commit it for now so that others can run it but not roll it into the dashboard yet
<prabhu>        Only the new blackbox tests
<prabhu>        and some of them might be test errors
<KenMartin>     Can those tests be modified to avoid the current failures?
<prabhu>        yes
<KenMartin>     Then the solution is to modify the tests to avoid those failures...
<KenMartin>     have a list of classes/tests to avoid right now
-->     hoffman (~hoffman at tripoint.kitware.com) has joined #vtk
<prabhu>        My idea was to make sure that others could reproduce it by 
using the sources and then fix them and gradually try to make it part of 
the regular 
<KenMartin>     and then over time we will reduce that list of exceptions
<prabhu>        Does that sound ok?
<prabhu>        ok
<KenMartin>     But the test must be part of the nightly testing
<prabhu>        Right now I think 3 classes segfaul.
<prabhu>        vtkLODProp3D vtkPropAssembly vtkRayCaster
<KenMartin>     Put those three classes in an exception list and add the test to the standard testing
<prabhu>        yes thats what I do.
<KenMartin>     Then as you have time debug those three classes so that there are no more exceptions
<KenMartin>     Sounds good
<prabhu>        others actually fail certain tests but not as serious as segfaults.
<prabhu>        I could trap them too and avoid testing them until they are fixed.
<prabhu>        I get the idea.
<KenMartin>     They will need to be excepted as well
<KenMartin>     good
<prabhu>        ok.
<KenMartin>     I think they will be a good addition
<legoandy>      So, vtkSetObjectMacro?
<prabhu>        KenMartin: thanks.
<KenMartin>     What is the issue on vtkSetObjectMacro?
<legoandy>      Well, I cleaned Hybrid, Patented and Parallel
<legoandy>      Goes actually pretty fast.
<legoandy>      One thing I noticed though was that vtkSetObjectMacro is not the only problem
<KenMartin>     Did it impact applications etc much?
<legoandy>      Anybody?
<legoandy>      (Paraview was minimally impacted...)
<Bigguy>        how?
<legoandy>      (It does build faster though)
<prabhu>        how much does it improve on compile time?
<legoandy>      The way application are affected is that some more things have to be included now when using Hybrid, patented and parallel
<legoandy>      couple of %
<legoandy>      The main improvement will show up when I(we) do the Common
<legoandy>      There is the source of all ...
<legoandy>      So, if people would be more carefull when including files 
in the header file, it would be cool.
<legoandy>      (At most one pure VTK class)
<legoandy>      Comments?
<KenMartin>     I assume the plan is to extend the testing to the other kits, yes?
<legoandy>      I added test to Rendering but I was moving, so I did not clean it yet.
<KenMartin>     I think it is a great idea and will fix some compiler (heap) issues we have been having. 
<KenMartin>     We just need to add a comment in the FAQ explaining that people may need
<legoandy>      After Rendering comes IO, Imaging and Graphics. Then finally Common
<KenMartin>     to include some include files that were being magically included before
<legoandy>      Well, I think the philosophy should be to include header for every VTK class you use
<legoandy>      This way there is no problems
<KenMartin>     Yup, I agree
<legoandy>      The header blockers will do the work for you
<KenMartin>     But in practice there is code out there that will need additional inckudes
<KenMartin>     Other issues on SetGetMacro
<legoandy>      Well, you upgrade toolkit, you have to do some modifications and if all you have to do is to add couple of include lines...
<KenMartin>     ???
<KenMartin>     Any other issues in general?
<prabhu>        Python examples.
<prabhu>        most examples seem to be Tcl based.
<Bigguy>        Testing of Examples
<prabhu>        Randy heiland wrote a neat tcl2py for 3.2
<prabhu>        Can I use it to translate some of the tcl examples
<prabhu>        and test them and then commit the resulting examples to the repository?
<KenMartin>     Do you mean examples or tests?
<prabhu>        examples
<prabhu>        we hear from users that there aren't enough Python examples
<prabhu>        and some folks have difficulty figuring out Tcl syntax etc.
<KenMartin>     For examples, they must be very well written and documented
<prabhu>        The docs from the Tcl examples will be translated.
<prabhu>        I'm talking of translating the existing Tcl examples to Python.
<KenMartin>     Why not translate an exisint example (like Tutorial/Step1 ro Step2 and email what the converted example looks like
<prabhu>        ok.
<KenMartin>     Bill, Testing Examples...
<KenMartin>     i guess the issue is that most are not tested?
<KenMartin>     Bill ?
<hoffman>       seb added a test for myVTK, but it needs the new cmake, and uses cmaketest
<Bigguy>        i'm back
<Bigguy>        ad a phone call
<--     hoffman has quit ("Client Exiting")
<KenMartin>     I think the main issue is just creating CMakeLists so that they can be tested
<KenMartin>     I don't see any problem with it
<Bigguy>        Do they use larger data?
<KenMartin>     It just needs to be done
<KenMartin>     I don't think they use larger data
<KenMartin>     Not positive
<Bigguy>        i can look into it
<KenMartin>     I'd say let's (as a team) focus on the coverage over the 
next week or two and then based on Bill's findings we'll look into the 
examples issue
<Bigguy>        sounds good
<Bigguy>        i think we can get coverage up over 80%
<KenMartin>     stretch goal :-)
<legoandy>      Also we should (as a team) clean VTK header files
<legoandy>      even more stretching ...
<prabhu>        One suggestion for the header file cleanup
<KenMartin>     I agree. Any suggestion Andy
<prabhu>        naming conventions.
<KenMartin>     Specificall?
<KenMartin>     Specifically?
<prabhu>        I've seen a few classes that have functions that dont have the right SetAToB methods
<prabhu>        let me check, its been a while.
<KenMartin>     OK
<legoandy>      So, here we go:
<KenMartin>     Those would be good fixes but I think they should be done after the include fixes
<legoandy>      Every header file includes at most one pure VTK class header file
<legoandy>      All other stuff is done in the cxx file
<prabhu>        Ok. Graphics/vtkExtractTensorComponents.h
<KenMartin>     OK, except for a few rare cases
<prabhu>        SetScalarMode.
<legoandy>      Such as?
<prabhu>        ScalarModeIsEffectiveStress
<KenMartin>     The #define issues we discussed earlier
<prabhu>        is non standard. I'd expect it to read
<legoandy>      Ok
<prabhu>        SetScalarModeToEffectiveStress
<legoandy>      I guess people should avoid that anyway
<KenMartin>     That's right prabhu
<KenMartin>     Andy are you asking for help?
<legoandy>      Well, I am asking for new classes
<legoandy>      I am working on a tcl script which will go through vtk header and cxx file 
<legoandy>      and check the validity of it
<legoandy>      then we can add parts to it
<KenMartin>     OK, and we should make sure any new classes we add follow the spec?
<legoandy>      For example, every vtkSet should have vtkGet and so on
<legoandy>      Yes
<prabhu>        cool.
<KenMartin>     Andy, can you update the coding convention page
<KenMartin>     to include the header include issue
<legoandy>      I can try, but I would like for us to first agree on what to add<KenMartin>     Right now let's limit it to  ....
<legoandy>      There is also an issue of assignment operators and copy constructor
<KenMartin>     each class should include only it superclass in the header file
<KenMartin>     Once that is true for all of VTK, we'll move on to the next issue
<legoandy>      Sounds good... I will do that
<KenMartin>     Thanks Andy
<KenMartin>     Other issues?
<legoandy>      Also, there are several people including stdio and similar ....
<legoandy>      All that should go out 
<Bigguy>        For next time, I'd like to talk about performance
<KenMartin>     Re: stdio, yup 
<Bigguy>        We are getting beat up on a regular basis by our customers
<KenMartin>     Sounds good Bill
<prabhu>        KenMartin: About the naming convention issue.
<legoandy>      Can we add tests that will test performance 
<legoandy>      Or, can we add something to dart?
<Bigguy>        we used to. Let's discuss next time.
<KenMartin>     The naming conventions, Prabhu if you could create a list of issues then present them next time?
<KenMartin>     Is that OK?
<prabhu>        ok. I wont commit anything before we discuss it then.
<Bigguy>        Must maintain compatibility
<prabhu>        yes
<prabhu>        I was thinking of adding the correct methods
<KenMartin>     Yup
<Bigguy>        that's ok
<prabhu>        so that things are fixed and yet backwards compat.
<legoandy>      But please add comment about it being depricated
<legoandy>      So that new code will not use them
<prabhu>        Should we deprecate it?
<KenMartin>     You can certainly add a comment, I would be careful about adding a message
<prabhu>        yes 
<legoandy>      Well, if it is wrong, we should depricate it. 
<Bigguy>        Our deprecation strategy sucks
<legoandy>      What we need is a compile time warning...
<prabhu>        Maybe in the comment string we could say use the other one instead.
<KenMartin>     Unfortunantly we can't really do that
<Bigguy>        we shopuld discuss at a future time
<prabhu>        Its not that its wrong its just inconsistent.
<legoandy>      How about adding compile time warnings to CMake
<legoandy>      Or maybe to wrapping
<KenMartin>     It will be easier with the list next time as well
<prabhu>        ok.
<KenMartin>     So let's shelve this issue until next time
<legoandy>      Ok
<prabhu>        ok.
<prabhu>        Many things to do anyway.
<KenMartin>     Thanks everyone
<Bigguy>        get some sleep!
<prabhu>        Thanks and congrats again!
<--     KenMartin (~kenmartin at cm-24-29-63-110.nycap.rr.com) has left #vtk

More information about the vtk-developers mailing list