[vtk-developers] IRC log for 21 May 2002.
Prabhu Ramachandran
prabhu at aero.iitm.ernet.in
Tue May 21 11:08:06 EDT 2002
hi,
Attached is today's IRC session log.
cheers,
prabhu
--------------------------------------------------
<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
testing.
<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