[vtk-developers] Tcl rendering tests and hangs

[Goodwin Lawlor]

On Sun, Apr 15, 2012 at 9:12 PM, Goodwin Lawlor <
goodwin.lawlor.lists at gmail.com> wrote:

>
>
> On Sat, Apr 14, 2012 at 8:01 PM, Goodwin Lawlor <
> goodwin.lawlor.lists at gmail.com> wrote:
>
>>
>>
>> On Sat, Apr 14, 2012 at 5:32 PM, Marcus D. Hanwell <
>> marcus.hanwell at kitware.com> wrote:
>>
>>> On Fri, Apr 13, 2012 at 7:31 PM, Goodwin Lawlor
>>> <goodwin.lawlor.lists at gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 13, 2012 at 4:45 PM, Goodwin Lawlor
>>> > <goodwin.lawlor.lists at gmail.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Apr 13, 2012 at 4:13 PM, Marcus D. Hanwell
>>> >> <marcus.hanwell at kitware.com> wrote:
>>> >>>
>>> >>> On Fri, Apr 13, 2012 at 11:09 AM, Goodwin Lawlor
>>> >>> <goodwin.lawlor.lists at gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Thu, Apr 12, 2012 at 6:35 PM, Marcus D. Hanwell
>>> >>> > <marcus.hanwell at kitware.com> wrote:
>>> >>> >>
>>> >>> >> On Wed, Apr 11, 2012 at 2:09 PM, Marcus D. Hanwell
>>> >>> >> <marcus.hanwell at kitware.com> wrote:
>>> >>> >> > Hi,
>>> >>> >> >
>>> >>> >> > I have a Gerrit topic up for review,
>>> >>> >> >
>>> >>> >> > http://review.source.kitware.com/#/t/374/
>>> >>> >> >
>>> >>> >> > This gets some of the rendering tests up and running again, but
>>> they
>>> >>> >> > hang until killed. Does anyone with deeper knowledge of Tcl and
>>> VTK
>>> >>> >> > have any idea what I might have missed. You can check out and
>>> build
>>> >>> >> > this topic, it depends on another topic that restores some Tcl
>>> code,
>>> >>> >> > and adjusts it for the new layout.
>>> >>> >> >
>>> >>> >> I have updated this topic, and have passing Tcl tests. The main
>>> point
>>> >>> >> I would love a little feedback on is why the additional require
>>> >>> >> package call was not necessary before modularization. I can
>>> confirm
>>> >>> >> that the image comparison is working, and I have to separate the
>>> tests
>>> >>> >> into two parts (Graphics and Rendering).
>>> >>> >>
>>> >>> >> Marcus
>>> >>> >
>>> >>> >
>>> >>> > Hi Marcus,
>>> >>> >
>>> >>> > Pre-modularization,  the vtk-tcl interpreter built with the vtk
>>> libs,
>>> >>> > initialized all the vtk commands on startup without a "package
>>> require
>>> >>> > vtk".
>>> >>> > That's the interpreter ctest uses to run rtImageTest.tcl.
>>> >>> >
>>> >>> > The question is, post-mod, what has changed that requires
>>> >>> > rtImageTest.tcl to
>>> >>> > have a "package require vtk".
>>> >>> >
>>> >>> > I'll have a look when I've got a new build.
>>> >>> >
>>> >>> Thanks for the explanation, I don't see where it was doing the
>>> package
>>> >>> require vtk before, and all the tests seem to have that as their
>>> first
>>> >>> line. For now we have merged the change, but I would welcome patches
>>> >>> if the old behavior is still desirable. We would also appreciate help
>>> >>> in restoring some of these tests if anyone still works with Tcl.
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Marcus
>>> >>
>>> >>
>>> >> The "package require vtk" wasn't been done before for the interpreter
>>> >> built with the vtk libs - the vtk commands were been initialized by
>>> the
>>> >> interpreter itself (in c) - have a look at vtkTkAppInit.cxx (if you
>>> have
>>> >> time!)
>>> >>
>>> >> If you were running vtk-tcl scripts with the interpreter above,
>>> "package
>>> >> require vtk" was (almost) redundant - but if you used your
>>> own/activestate's
>>> >> interpreter and built dynamic vtk libs with tcl wrappers, then you
>>> needed
>>> >> "package require vtk".
>>> >>
>>> >> The merged change is fine - it's unlikely but someone may run the
>>> >> regression tests manually with a different interpreter and now they
>>> will
>>> >> work.
>>> >>
>>> >> I'll build from master today and have a look through the tcl stuff
>>> over
>>> >> the weekend. We still use vtk-tcl in our lab...
>>> >>
>>> >> Goodwin
>>> >>
>>> >
>>> > Just fyi, here's the diff that caused the above problems
>>> >
>>> >
>>> http://vtk.org/gitweb?p=VTK.git;a=blobdiff;f=Wrapping/Tcl/vtkTkAppInit.cxx;h=8a6001416a69cf1ede821bce50c53f627768cd80;hp=857af94651b9f5366ede9ca9f62dad14c58d3229;hb=0c1471f1da0ee8d76e9db0d95a0c434f0b38a7f5;hpb=cdd4d6fdec8b4b2c143224ca1d94699c96a8b58a
>>> >
>>> > The init code was chopped out of vtkTkAppInit.cxx since it reflected
>>> the old
>>> > structure, I guess.
>>> >
>>> > I think it's better off this way, anyway.
>>> >
>>> I made that change, thanks for pointing out the change. If people want
>>> to bring it back I will know where to add the code back in now. I feel
>>> like it is better, but if it breaks a lot of old code I could see some
>>> argument for bringing it back.
>>>
>>> Marcus
>>>
>>
>> I discovered why the tcl interpreter was initialized like it was - it
>> seems to be for the benefit of static builds, to force the linkage of
>> static vtk libs.
>>
>> Instead of re-instating the old code, it would be better to use the tcl
>> function "Tcl_StaticPackage" to link in the vtk static libs. This would
>> mean that the vtk commands only become available in a tcl interpreter after
>> a "package require vtk" regardless if the build is shared or static...
>> which is the way it should be.
>>
>> BTW, the cmake variables:
>>
>> VTK_USE_TK
>> VTK_TCL_TK_STATIC
>>
>> were absent from the modular build. There were declared in the root
>> CMakeLists.txt file.
>>
>> VTK_TK_RESOURCES_DIR
>>
>> was no longer being set.
>>
>> The Tk include directories weren't being included...
>>
>> I've got a static build with Tk working now, so I'll push something to
>> gerrit to review.
>>
>>
> Here's my topic for review: http://review.source.kitware.com/#/t/415
>
> A static modular vtk tcl build is working now.
>
> Thanks,
>
> Goodwin
>

A topic for adding the Tcl tests for Common/*

http://review.source.kitware.com/#/t/416

Running these tests, throws up some bugs in:

vtkAMREnzoReader
vtkAMREnzoParticlesReader
vtkStreamTracer
vtkProgrammableElectronicData
vtkTestingObjectFactory

I'll submit a different topic for the fixes for these. Empty input bugs
mainly...

Goodwin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120416/2b390f71/attachment.html>