[vtk-developers] Tcl rendering tests and hangs

Mon Apr 16 10:28:24 EDT 2012

Hi Andrew,

Thanks for testing this out. I could have damaged something for a shared
build.

I'll do a fresh shared build now and check out what's happening

Thanks,

Goodwin

On Mon, Apr 16, 2012 at 7:43 AM, Andrew Maclean
<andrew.amaclean at gmail.com>wrote:

> Hi Goodwin,
>    I don't know whether this is related, but I suspect it is, am seeing
> two things (dynamic builds of VTK):
> 1)
>    a) In Linux,the TCL scripts run but there is no output on the opengl
> window - it just remains white.
>    b) In Windows the scripts run normally producing output on the window.
>    c) You can test this with any script in VTK/Examples/Medical/Tcl/
> 2) The Tcl interpreter is definitely hanging and it is not possible to
> close the output window in both Windows and Linux.The behaviour in windows
> is new, previously you were able to close the window, I no have to kill the
> wish85.exe process in the task manager. The maximize and minimize buttons
> work OK but the close window (exit) button does not work.
>
> Regards
>    Andrew
>
>
>
>
>>
>> ---------- Forwarded message ----------
>> From: Goodwin Lawlor <goodwin.lawlor.lists at gmail.com>
>> To: "Marcus D. Hanwell" <marcus.hanwell at kitware.com>
>> Cc: VTK Dev <vtk-developers at vtk.org>
>> Date: Mon, 16 Apr 2012 03:06:20 +0100
>> Subject: Re: [vtk-developers] Tcl rendering tests and hangs
>> 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
>>
>> _______________________________________________
>> vtk-developers mailing list
>> vtk-developers at vtk.org
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120416/a7487cb0/attachment.html>