[vtk-developers] IRC Session log for Tue Jul 16 2002

Tue Jul 16 11:07:59 EDT 2002

**** BEGIN LOGGING AT Tue Jul 16 09:55:55 2002

<legoandy>	hi prabhu
<prabhu>	hi
<SebBarre>	Hi
<prabhu>	Seb, the ftgl stuff looks very nice. thanks.
<KenMartin>	Good morning folks, why don't we get started
<KenMartin>	I have three items on the agenda right now
<KenMartin>	1) The new text mappers
<prabhu>	Ok, adding SetRefCount to vtkObject (via vtkObjectBase) is that ok?
<KenMartin>	2) CMake 1.4
<KenMartin>	3) vtkString
<KenMartin>	4) adding SetRefCount
<KenMartin>	Starting with (1) Thanks Sebastien for doing a great job with the text mappers
<KenMartin>	It looks like they are working pretty well
<KenMartin>	and many platforms that had text problems seem to be OK now
<SebBarre>	Thanks Ken, they look OK. Thanks for being patient :)
<prabhu>	yes and it looks nice altho the fonts look bigger than they used to (which is not a hassle).
<legoandy>	MS Visual Studio 6 release still crashes 5 tests
<KenMartin>	font related?
<prabhu>	Hmm, one thing with the ScalarBar and Axes actors -- long standing bug
<prabhu>	If you reset the font factor
<prabhu>	the font factor will not change unless the window is resized.
<SebBarre>	lego: are you sure ? I detected the leak yesterday and send a fix.
<legoandy>	Looks like... They started crashing after fonts
<legoandy>	They crashed today
<KenMartin>	I think the scalar bar and axes actor are both on the short list for a clean up
<KenMartin>	both classes have problems
<prabhu>	oh ok
<SebBarre>	lego : yes, I can see that.
<KenMartin>	There are also some long standing SIGFPE issues on the dec that will someday get investigated
<KenMartin>	On to (2)
<KenMartin>	We have cut Cmake 1.4 and packaged it up and moved the LatestRelease tag
<KenMartin>	I will announce it shortly
<SebBarre>	prahbo: I'll look at it at some point, but I'm pretty sure I made a lot of tests to check that the MTime are right. I'll keep u posted
<KenMartin>	and then after that I will update the VTK files to use 1.4
<legoandy>	Means I can finish Java build and vtkpython
<KenMartin>	So that means you must upgrade to CMake 1.4 soon
<prabhu>	Seb, the mtime for the font change is not checked IIRC (I looked very long ago tho)
<KenMartin>	Item (3) vtkString
<KenMartin>	There is a helper class called vtkString that provides some ease of use functionality
<SebBarre>	prabhu: oh, if you did not check recently, then I can tell you that I fixed most of these MTime issues while switching all actors to vtk TextProperty
<KenMartin>	Andy want to provide a brief desc of its usefulness
<legoandy>	He he
<SebBarre>	Ken: speaking of vtkString, it reminds me the container. Can we start using them ?
<legoandy>	Well, 
<legoandy>	Strings in C are a pain... 
<KenMartin>	Seb, Lets disc string first
<legoandy>	Unfortunately they are pretty fast compare to some string class
<legoandy>	Also, people are used to using them certain way
<legoandy>	this changed with some new compilers such as .NET
<legoandy>	.NET complains for example when you assign strlen to int
<legoandy>	also, there is an issue of strdup, which uses malloc not new
<legoandy>	and of cousrse the readability of strcmp
<legoandy>	So, vtkString packages all this but maintain the speed of C style strings
<legoandy>	And  it is readable
<KenMartin>	vtkString is not a container, but simply provides some utility functions for use such as vtkString::Length(const char *)
<SebBarre>	is it for internal use, or do we plan to change the whole API ?
<legoandy>	For internal use only
<legoandy>	It operates on char *
<legoandy>	So you can mostly just replace existing code
<hoffman>	So vtkString is really a name space for a group of functions that work with const char*?
<legoandy>	strlen(foo) = vtkString::Length(foo)
<legoandy>	yes
<KenMartin>	I feel that vtkString doesn't provide enough benefits to warrent the departure from standard C routines such as strlen
<KenMartin>	warrant (sp)
<hoffman>	I would expect vtkString to be a class that handled string memory
<legoandy>	also, I am planning to add case insensitive compare
<SebBarre>	ah ok, I did not get that, just a namespace
<legoandy>	do we need a string class?
<kingb>	I would call it vtkStringTools or something indicating a namespace.
<hoffman>	vtkString is like vtkMath right now
<legoandy>	MAkes it loong and ..
<KenMartin>	Any other thoughts?
<KenMartin>	OK, we will drink some beer and figure it out later
<prabhu>	ok.
<KenMartin>	Item (4) SetRefCOunt Prabhu
<prabhu>	yes
<prabhu>	I understand that SetREfcount is dangerous etc. and the reason I asked for it is rather selfish
<legoandy>	Explain
<prabhu>	The older API had exposed Set and Get Reference count
<prabhu>	In the vtkPipeline browser I remove these methods when I generate the GUI
<kingb>	In what situation is SetReferenceCount useful?  Breaking refcount loops?
<prabhu>	Now some folks check out VTK cvs and run the browser and things dont work.
<prabhu>	So I need to add the method back into vtkObject to keep things consistent
<prabhu>	I dont use it.
<legoandy>	How about dir(foo)
<prabhu>	Its just that it used to be there and isnt there anymore.
<legoandy>	I mean in python you can check if a method exists
<prabhu>	and folks who download the pipeline browser have difficulty when they use cvs.
<prabhu>	so yes, its selfish.
<prabhu>	of course
<KenMartin>	So new versions of your browser can be modified to handle it not being there (if version >) ...
<kingb>	We could put it in with an annoying deprecation warning when called.
<prabhu>	they already are.
<prabhu>	the cvs version of the browser already deals with the issue
<KenMartin>	but your old version clearly doesn't have the logic to handle it
<prabhu>	its a non-issue.
<prabhu>	yes
<KenMartin>	I get it.  We could put it in with a deprecated message and remove it before 4.2 is released
<legoandy>	Once somebody fixes python wrappings, to include vtkObjectBase this should go away?
<KenMartin>	Woudl that solve your issue?
<prabhu>	yes, possibly.
<KenMartin>	Where "somebody" is David G I assume?
<prabhu>	Its really not a big deal.
<prabhu>	Yes.
<prabhu>	But David seems very busy these days.
<KenMartin>	If it isn;t a big deal then lets leave it out and hope that David updates the Python wrappers.
<KenMartin>	Other issues?
<kingb>	vtkCollectionIterator is now available for those interested.
<legoandy>	VTK Java and vtkpython
<prabhu>	Its just an irritation for some of the browser users but really its no big deal I could always keep a patch ready.
<KenMartin>	As Seb asked, are the containers ready?
<legoandy>	vtkpython seems to be working on all platforms I tested
<prabhu>	what are the issues with vtkpython?
<legoandy>	and I tested VTK Java build on Linux and Windows and it works
<SebBarre>	are the containers ready folks ?
<prabhu>	Are there any vtK python users here apart from me?  If so I'd like to discuss some python testing issues.
<legoandy>	I thought there were some problems
<legoandy>	Containers are ready
<SebBarre>	and did you had any pb with template instantiations (i.e. can we have template in declarations ?)
<legoandy>	vtkArrayMap has to be reimplemented to be more efficient and explcit instantiation has to be fixed
<legoandy>	You have to BTX/ETX it
<prabhu>	Actually, if we are not going to add SetReferenceCount why do we need to add GetReferenceCount?
<legoandy>	And it has to be in private or protected section
<kingb>	GetReferenceCount is great for debugging.
<SebBarre>	OK, I'm just asking since to remove the STL dependency in FTGL I created a small vector class, with macro instantiation instead of real instantion, waiting for you guys to investigate the pb. I'll stick to macro, it's working OK, and it's a minor detail lost in Utilities/ anyway
<legoandy>	Well, getrefcount is more usefull
<kingb>	SebBarre: you can't use the containers from the Utilities directory anyway.
<SebBarre>	I know
<prabhu>	Yes, true.
<SebBarre>	I'm not going to put dependency between Utilities/ and VTK
<legoandy>	Once python wrapping is fixed getrefcount goes to mr. attc
<prabhu>	what is mr. attc?
<legoandy>	/dev/null
<prabhu>	oh
<legoandy>	in CVS terminology
<KenMartin>	So the containers mostly work except for explicit instantian when instantiated in multiple libraries?
<legoandy>	I guess
<prabhu>	But getrefcount is useful for debugging
<SebBarre>	BTW, I do not remember who asked me for that, but text rendering works offscreen now
<prabhu>	cool.
<legoandy>	But when python wrapping is fixed it will come from vtkObjectBase
<prabhu>	oh
<kingb>	KenMartin: yes, we need to establish a policy about where to put explicit instantiations.
<KenMartin>	You don't remeber who asked because they asked so long ago :-)
<SebBarre>	ouch
<legoandy>	containers are already being used (and tested in python wrapping)
<prabhu>	But are there plans to "fix" the python wrappers?
<legoandy>	yes
<legoandy>	(this answer is subject to change)
<KenMartin>	Other issues?
<SebBarre>	Burn magrathea, burn...
<SebBarre>	otherwise no, no other issues
<legoandy>	VTK Java... Commit or not?
<legoandy>	Fix it...
<prabhu>	Will the vtkpython executable be built once we move to Cmake1.4?
<legoandy>	yes
<legoandy>	Hopefully
<KenMartin>	Let me check in the updated CMakeLists files first, then you can merge in the VTK Java stuff
<legoandy>	I tested on couple of platforms
<prabhu>	ok could you let me know so I will fix the setup.py appropriately.
<hoffman>	someone on the list suggested we make an option so that some of the stuff in utilities in not compiled, but the system version is used instead (jpeg, tiff)
<SebBarre>	I don't think it's reasonable
<KenMartin>	We had that at one point and I think we dropped it due to problems
<prabhu>	mea culpa.
<kingb>	That would allow applications to use the system libs without getting multiple symbols.
<SebBarre>	our Utilities/* compile sometimes on more platforms now than they used to be
<KenMartin>	I don't recall what the problems were though
<KenMartin>	Maybe we will look into it again, low priority, but I understand the motivation
<prabhu>	Did you run into version related problems with libraries.  A while back there were two versions of jpeg libs and they caused some headache.
<prabhu>	that would be great. thanks.
<legoandy>	isn't python linked with java and expat?
<KenMartin>	I don't remember, I think it was version problems with some OS versions 
<prabhu>	One question.
<prabhu>	Why don't the VTK libs have version numbers themselves.
<prabhu>	So that we can differentiate between 4.0 and 5.0 say.
<KenMartin>	I want to add this, also a debug option vtkCommon42d.dll
<KenMartin>	I will probably stick this in before VTK 4.2 is released. I have wanted it since before VTK 3.2
<hoffman>	That would cause quite a lot of applications built on vtk to stop building....
<kingb>	That's what symlinks from libvtkCommon.so -> libvtkCommon.so.4.2 are for.
<kingb>	At least on unix..
<prabhu>	legoandy: python is not linked with java.
<hoffman>	No sym links for .dlls
<KenMartin>	Not really, CMake can handle it, if they are not using CMake then they will update
<KenMartin>	We don;t have releases of VTK that frequently
<KenMartin>	It also solves a lot of the multiple VTK on one system problems when people upgrade
<prabhu>	yes.
<legoandy>	sounds good
<prabhu>	In fact the debian maintainer goes through some hoops to add version numbers etc.
<KenMartin>	Other Issues?
<KenMartin>	Going...
<KenMartin>	Going...
<prabhu>	one sec.
<legoandy>	That was a minute almost
<prabhu>	You mean you do plan on adding version numbers to the libs?
<prabhu>	I'm hungry and my typing is all awry. :)
<prabhu>	yes?
<KenMartin>	Yes
<prabhu>	great. thanks.
<KenMartin>	Was that it?
<prabhu>	yes. :)
<KenMartin>	Going...
<KenMartin>	Going...
<KenMartin>	Gone
<KenMartin>	Thanks Folks
<prabhu>	bye
**** ENDING LOGGING AT Tue Jul 16 10:48:43 2002