[vtk-developers] IRC session: April, 23, 2002
Sebastien BARRE
sebastien.barre at kitware.com
Tue Apr 23 11:14:06 EDT 2002
Here is a transcript of the first VTK-developers IRC session, April 23,
2002, 10 AM EST.
It lasted approx. 55 minutes.
Contributors:
- David Gobbi
- John Biddiscombe
- Charles P. Botha
- Lisa Avila, Andy "Lego" Cedilnik, Berk Geveci, Amy Henderson, Bill
Hoffman, Ken Martin, Will Schroeder, Sebastien Barre
<KenMartin> Well I think we have waited long enough, lets get started
<dgobbi> I'm connected through a lousy irc program right now, I'm going to
come back on xchat.
<KenMartin> As a quick note I have updated the FAQ and added a couple
roadmap items
<dgobbi> Back in 5 (or less).
<KenMartin> It is a first take at open to do items and plans
<seb_> ken: what item ?
<KenMartin> FAQ Entries 6.10 and 6.11
<KenMartin> Also I note that the changes to VTK since version 4.0 is still
almost empty
<will> I'll add stuf about the 3D widgets and interactor observer
<KenMartin> It would help with the releases if people could keep that item
up to date
<jb_> will there be a polyline widget for selecting regions?
--> dgobbi (~dgobbi at banquo.irus.rri.on.ca) has joined #vtk
<dgobbi> I'm back.
<KenMartin> Will can you put the new widgets stuff into the FAQ ?
<will> aye aye
<KenMartin> Bill update the interactor stuff?
<hoffman> OK.
<KenMartin> Have there been any other changes since 4.0 I'm forgetting?
<hoffman> Brad's create object by string name stuff.
<will> some new classes like vtkBandedPolyDataContourFilter
<legoandy> vtkReferenceCount
<will> Brad's vtkXMLParser
<KenMartin> OK, I'll mention that to Brad, who did the banded pdf ?
<legoandy> libtiff
<will> I did the banded with jeff lee
<legoandy> expat
<seb_> Ken: Might be worth mentioning vtkGenericRenderWindowInteractor, it
might really help Tk users
<KenMartin> Andy can you add some info on the TIFF stuff
<legoandy> Ok
<KenMartin> Will can you add a brief sentence on the banded to the FAQ?
<will> Is someone keeping a log of this conversation?
<hoffman> Does this chat session get saved?
<seb_> not that I know
<will> I will write up banded
<seb_> I'll check that
<jb_> you can cut and paste the stuff you can see
<hoffman> I see a save buffer option on xchat...
--> avila (~avila at tripoint.kitware.com) has joined #vtk
<dgobbi> My buffer is unlimited, so I can save the whole session...
<KenMartin> Other issues?
<legoandy> vtkReferenceCount
<legoandy> :)
<dgobbi> vtkBaseObject, vtkBasicObject are still my favorites
<dgobbi> Just in case it does more than just reference counts in the future.
<KenMartin> Remind me, you want to move ref count and getclassname and
debug into a superclass?
<legoandy> yes
<jb_> what's left in vtk objwect
<legoandy> This way we can make vtkCommand and vtkContainer also subclasses
of that and they can use vtkSetGet
<KenMartin> How does getclassname fit into templated classes? You just
ignore the template params?
<legoandy> We keep events in vtkObject
<legoandy> It will just return the name of the class w/o templated parameter
<KenMartin> vtkObject has ModifiedTime also
<KenMartin> Debug adds two to four bytes to the footprint of the objects
<legoandy> const char* vtkVector<T>::GetClassName() const { return
"vtkVector"; }
<legoandy> Isn't debug compile time thing?
<KenMartin> No, it is always there
<legoandy> Huh, then we can maybe modify vtkSetGet to be "smarter" about that
<legoandy> VTK_USE_DEBUG
<KenMartin> You want to add these so Set/Get macros work
<legoandy> or VTK_CLOBBER_CLASSES
<legoandy> Well, I don't want to increase the footprint of the containers
and commands
<legoandy> (Other people are welcome to comment too)
<jb_> we're listening :)
<seb_> ok, I'm logging from now on.
<legoandy> So?
<KenMartin> Hmmm, I like the idea of using SetGet macros but I'm concerned
about the footprint
<jb_> does footprint matter when datasets are MB
<legoandy> How about if we take debug stuff from run time to compile time?
<legoandy> The footprint matters when you have let say array of arrays
<_amy_> I think you want to be able to say vtkObject::DebugOn without
recompiling VTK.
<KenMartin> Normally the footprint doesn't matter except some classes may
create millions of containers
<avila> is the only issue the debug flag? If so, I think the #ifdef
solution is a good one - then you do have the opportunity not to have those
conditionals in all the set/get methods.
<KenMartin> Spatial Hash comes to mind
<will> like the locators (have vtkIdlists)
<KenMartin> The ifdef is already there, VTK_LEAN_AND_MEAN or something like
that
<jb_> ok
<avila> so the footprint would only increase if VTK_LEAN_AND_MEAN were off?
Or is something else increasing it besides the debug flag?
<legoandy> Looks like it is already done this way
<KenMartin> It is the Debug flag, but the default is for it to be present
<KenMartin> I'd like a solution where the default behaviour is reasonable
<legoandy> So, we clean debug and we are ok
<KenMartin> What does clean debug mean?
<legoandy> Default behaviour IMHO is without debug
<legoandy> Well, make debug be present only in Lean&MEan
<KenMartin> That is a big change for DebugOn not to work by default
<legoandy> What does DebugOn do anyway?
<legoandy> vtkDebugMacro is disabled by defaul
<legoandy> (t)
<seb_> no
<legoandy> Huh, never mind
<avila> yes, but you can turn it on without recompiling
<legoandy> I see
<legoandy> So it is all done in run-time
<KenMartin> Yes
<seb_> Ken: going back to footprint, do you have real numbers. I mean, if
it's only a matter of footprint...
<_amy_> DebugOn prints out debugging statements (things inside
vtkDebugMacro statements) for the class it was turned on for.
<avila> Can we have a no debug version of the set/get macros?
<legoandy> If we do this, then we esentially have to modify all classes
<avila> why do we have to modify all classes?
<KenMartin> The container footprint right now is small. If Andy removed the
vtable from the conatiners then it is very small
<legoandy> Well, "all" classes use vtkDebugMacro
<legoandy> Sorry
<legoandy> All classes use vtkSetGet macros
<legoandy> If we now make one for debug and one for no debug, we have to
modify all classes that use them
<avila> no - make another version of the set/get macros (different name)
that doesn't use the debug flag.
<legoandy> vtkSetStringDebugMacro?
<legoandy> vtkSetStringNoDebugMacro?
<KenMartin> That doesn't help because the Debug ivar is in vtkBasicObject
<avila> Why does it need to be in vtkBasicObject?
<avila> I though the only reason was to use the set/get macros
<legoandy> Well, we can keep it in vtkObject and use a separate set of macros
<legoandy> but, then we might as well write a whole set of new ones
<avila> That is my suggestion. It doesn't increase the memory footprint.
<will> suggestion: please use vtkObjectBase. This is consistent with ITK.
It also indicates that it is a base class for the purposes of derivation.
<KenMartin> For now why don't we skip the Set/Get macros and just do the
reference counting?
<legoandy> So, comments on this: copy "all" macros in vtkSetGet and move
reference counting and GetClassName to vtkObjectBase/vtkBaseObject?
<legoandy> What else should go there?
--> burp (~cpbotha at dutidad.twi.tudelft.nl) has joined #vtk
<hoffman> Wasn't one of the big reasons for the confusing Set/Get macros
the Modified time, which this would not have?
<burp> Does anyone mind if I sit here in the corner and watch?
<KenMartin> No problem
<burp> :)
* burp sits in the corner
--- burp is now known as CharlBotha
--- CharlBotha is now known as cpbotha
<KenMartin> What does it cost to add the GetClassName?
<legoandy> Well, nothing
<KenMartin> Just a class static?
<legoandy> Just some work on developers (me) part
<will> GetClassName() is virtual -> vtable results
<KenMartin> Yup, but Register UnRegister need to be virtual as well so...
<will> yup, minor
<KenMartin> OK so lets put refcount and GetClassName into this class
<legoandy> The thing about vtable is that footprint is only one unit bigger
<legoandy> All the set/get methods in containers are not virtual so they
are fast
<KenMartin> What does vtkObjectBase mean will? The name is confusing to me?
<will> In ITK we adopeted "Base" to indicate the root of a hierarchy
<KenMartin> So by that definition vtkObject should already have been named
vtkObjectBase?
<_amy_> so why not vtkBaseObject?
<will> A hierarchy of derivation: the base class and derived classes
<will> We've been trying to use a naming rule in ITK that goes from
specialied->general
<will> of course vtk has no real rule that I'm aware of
<will> specialized to general means the tail end of the name is general,
qualifiers precede it
<KenMartin> Suggestions on the table are vtkBasicObject vtkBaseObject
vtkObjectBase any others people support?
<will> I've also seen vtkLightObject (spelled correctly andy)
<avila> too confusing
<jb_> vtkBaseObject or vtkObjectBase are both nioce. But in My view,
vtkObject should be the lowest obne and the existing vtkObject should be
renamed in accordance with its new role
<legoandy> The problem with that is again we would have to fix "all" the vtk
<avila> too big a change - any one out there that derived an object from
vtkObject would have to change their code
<KenMartin> We can't rename vtkObject, too many classes subclass off of it,
but you are correct
<jb_> I see. I'd forgotten about the users...(again)
<KenMartin> Other opinions?
<avila> If it were just VTK it would take less time to reparent these
classes than to decide on a name....
<legoandy> We could start from scratch... :)
<legoandy> So how would you call the subclass of vtkObject?
<jb_> I didn't dare think about that
<seb_> just throw a coin, we have good candidate already
<KenMartin> vtkObservableObject with a vtkTimeStampObject subclass
<jb_> but something like vtkFlaggedObject
<legoandy> Are you seriously considering this?
<KenMartin> Why don't we go with vtkObejctBase, and disagreement?
<KenMartin> spelled correctly of course
<avila> sounds good to me
<seb_> vtkSpelledCorrectlyObjectBase /
<legoandy> Actually misspelled would be better because it would discurrage
people from using it
<KenMartin> going going...
<jb_> gone
<legoandy> So, vtkObejctBase?
<dgobbi> Yes! Go with it.
<KenMartin> Any other issues?
<legoandy> Still no Prabu
<jb_> We'll send him a card
<hoffman> He was here for a second or two
<legoandy> With printout of IRC log?
<will> send him the log file
<dgobbi> My main concern right now is customizing interaction in scripting
languages.
<legoandy> that was some french dude
<KenMartin> Thanks for the participation folks, can someone email a log to
vtk-developers?
<legoandy> dgobbi: we could ditch the TCL
<seb_> ken: I have the log
<dgobbi> legoandy: Would that be the solution?
<KenMartin> You're it seb. Thanks
<-- KenMartin (~ken at tripoint.kitware.com) has left #vtk
<-- will (~somebody at tripoint.kitware.com) has left #vtk ("Client Exiting")
<-- _amy_ (~AMY at tripoint.kitware.com) has left #vtk
<jb_> Can I puit t python window inside my C++ gui as easily as a TCL one?
<legoandy> probably
<jb_> cheerio - must get some work done
<-- jb_ has quit ("Client Exiting")
<seb_> david: if you have the early beginning of the chat, can you give it
to me ?
<dgobbi> I'll email the whole thing to you, from 10:10 onwards.
<seb_> thanks, I just missed the first mins
<dgobbi> As for embedding python in C++, I've done it, it is possible, I
don't do it on a regular basis.
<dgobbi> It's really not much different than with tcl or tk.
<-- hoffman has quit ("Client Exiting")
<legoandy> Well, back to work. Lets do this in about a week or so again
<dgobbi> Actually, I've got work to do, too...
<legoandy> ttl...
<dgobbi> Got a PhD I have to finish one of these years.
<legoandy> :)
<seb_> ok
<legoandy> bye
<-- legoandy has quit ("Client Exiting")
<seb_> Bye, thanks for joining
<-- seb_ (~sebastien at tripoint.kitware.com) has left #vtk
--
Sebastien Barre
More information about the vtk-developers
mailing list