[vtk-developers] Request: turn off BTX/ETX in some dashboad builds

David Gobbi david.gobbi at gmail.com
Wed Jul 14 23:34:25 EDT 2010


It looks like the switch to VTK_IGNORE_BTX didn't take, because I set
the variable type to BOOLEAN instead of BOOL.  That's a bummer.  I'll
have to try again tomorrow.

   David



On Wed, Jul 14, 2010 at 12:23 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> I'll pull the switch at 4pm ET, by forcing VTK_IGNORE_BTX to ON.  In
> the morning I will un-force the option, but leave it with a default
> "ON" setting.
>
>   David
>
>
> On Wed, Jul 14, 2010 at 11:25 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> It would be great if this idea was expanded upon to provide other
>> wrapper hints via doxygen.  The wrapping hints file is a very ugly
>> thing, and it would be nice if the @return statement could provide the
>> hint about how many returned values there are.
>>
>> For introspection, if there was some VTK code that could read a string
>> containing a doxygen comment and then provide contract information
>> that could be used by the wrappers and the tests, that would be
>> incredibly useful.
>>
>>   David
>>
>>
>> On Wed, Jul 14, 2010 at 11:15 AM, Francois Bertel
>> <francois.bertel at kitware.com> wrote:
>>> The last ARB meeting mentionned the wrapping changes.
>>>
>>> ref: http://www.vtk.org/Wiki/VTK/ARB/Meetings/July_2010
>>>
>>> One possible way to address Set/Get that fail would be to add some
>>> contract-based documentation that would exclude some set/get from
>>> testing.
>>>
>>> A way to implement that could be to use the doxygen \pre keyword to
>>> document preconditions.
>>> TestSetGet could detect lines with \pre and therefore skip to run the
>>> Get/Set methods attached to the documentation.
>>>
>>>
>>> On Wed, Jul 14, 2010 at 12:59 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>>> You have mine and David Partyka's support to flip the switch, David Cole
>>>> already expressed his support. I can push the ParaView and Titan VTK
>>>> submodules forward too. I am not sure where Berk or Will are, but I think it
>>>> would be good to see a run of the nightly dashboards for these projects too.
>>>> Thanks,
>>>> Marcus
>>>> On Wed, Jul 14, 2010 at 11:55 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>
>>>>> Getting back to the BTX/ETX issue, it would like to request permission
>>>>> to turn off BTX/ETX detection in the wrapper code for at least one
>>>>> night so that I can see how all the dashboard machines react.
>>>>>
>>>>> Last week me and Marcus ran experimental dashboards on Linux, Win32,
>>>>> and OS X and only two tests failed as a result of the change:
>>>>> TestTkRenderWidgetPython (which I've fixed) and TestSetGet (which
>>>>> fails because removing BTX/ETX causes many addition Set/Get methods to
>>>>> be wrapped).  ParaView also continued to compile and test with no
>>>>> errors, which was expected because the "IGNORE_BTX" option is
>>>>> currently limited to VTK's own classes and does not apply to external
>>>>> VTK classes.
>>>>>
>>>>> So what do people think?  Should I wait, or can I pull the switch this
>>>>> afternoon?
>>>>>
>>>>>  David
>>>>>
>>>>>
>>>>> On Fri, Jul 9, 2010 at 3:27 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> > Okay, my VTK_IGNORE_BTX Win32 test finished (just nmake, not devenv).
>>>>> > Exactly the same expected failures: TestSetGet and
>>>>> > TestTkRenderWidgetPython
>>>>> >
>>>>> >  http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=660432
>>>>> >
>>>>> > The TestTkRenderWidgetPython test failure really does seem to be due
>>>>> > to the fact that this is an old crufty test, since the
>>>>> > vtkTkRenderWidget actually does work in Python.
>>>>> >
>>>>> >  David
>>>>> >
>>>>> >
>>>>> > On Fri, Jul 9, 2010 at 12:01 PM, David Gobbi <david.gobbi at gmail.com>
>>>>> > wrote:
>>>>> >> I just built ParaView on linux64 with VTK_IGNORE_BTX and it looks good:
>>>>> >>
>>>>> >> The following tests FAILED:
>>>>> >>         27 - PrintSelf-PVServer-Common (Failed)
>>>>> >>         28 - PrintSelf-PVServer-Filters (Failed)
>>>>> >>         29 - PrintSelf-PVServer-ServerManager (Failed)
>>>>> >>         97 - pvcs.PropertyLink (Failed)
>>>>> >>        137 - pvcrs.PropertyLink (Failed)
>>>>> >>
>>>>> >> The PrintSelf tests always fail on my machine, and the PropertyLink
>>>>> >> tests are also failing on the continuous dashboard, so no worries
>>>>> >> about them either.
>>>>> >>
>>>>> >> Here are the results for an OSX 10.6 build of just VTK by itself:
>>>>> >>
>>>>> >> The following tests FAILED:
>>>>> >>         65 - TestSetGet (SEGFAULT)
>>>>> >>        751 - TestGaussianBlurPass (Failed)
>>>>> >>        768 - TestOpacity (Failed)
>>>>> >>        783 - TestTranslucentLUTDepthPeeling (Failed)
>>>>> >>        784 - TestTranslucentLUTDepthPeelingPass (Failed)
>>>>> >>        786 - TestTranslucentLUTTextureDepthPeeling (Failed)
>>>>> >>        843 - TestTkRenderWidgetPython-image (Failed)
>>>>> >>
>>>>> >> All those GPU tests always fail on my system, so only the TestSetGet
>>>>> >> and TkRenderWidgetPython tests concern me, and both are expected.
>>>>> >>
>>>>> >> So I'd have to do nmake and devenv builds to be sure, but it looks
>>>>> >> like VTK_IGNORE_BTX is a pretty safe option now.
>>>>> >>
>>>>> >>   David
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Fri, Jul 9, 2010 at 10:10 AM, David Gobbi <david.gobbi at gmail.com>
>>>>> >> wrote:
>>>>> >>> Thanks.  I've seen TestTkRenderWidget failures, too, and I suspect
>>>>> >>> that the test itself is broken.
>>>>> >>>
>>>>> >>> I've just pushed my safer BTX/ETX ignore code.  This should allow
>>>>> >>> VTK_IGNORE_BTX to be used even with ParaView and Titan.
>>>>> >>>
>>>>> >>>   David
>>>>> >>>
>>>>> >>>
>>>>> >>> On Fri, Jul 9, 2010 at 9:45 AM, Marcus D. Hanwell
>>>>> >>> <marcus.hanwell at kitware.com> wrote:
>>>>> >>>> On Fri, Jul 9, 2010 at 11:38 AM, David Cole <david.cole at kitware.com>
>>>>> >>>> wrote:
>>>>> >>>>>
>>>>> >>>>> On Fri, Jul 9, 2010 at 11:16 AM, David Gobbi <david.gobbi at gmail.com>
>>>>> >>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> The one dashboard test that is guaranteed to break is TestSetGet.
>>>>> >>>>>> Some of the BTX'd methods are Get methods that segfault when they
>>>>> >>>>>> are
>>>>> >>>>>> called, and if BTX is ignored, then TestSetGet will call them.
>>>>> >>>>>> These
>>>>> >>>>>> methods will either have to be fixed or excluded from TestSetGet.
>>>>> >>>>>
>>>>> >>>>> The main point of that test is to ensure that any Get method may be
>>>>> >>>>> called
>>>>> >>>>> directly after instantiating any VTK object. I would argue for
>>>>> >>>>> fixing, not
>>>>> >>>>> excluding. VTK should not crash if somebody "accidentally" calls a
>>>>> >>>>> Get
>>>>> >>>>> method before the object is ready for it. It should just return 0,
>>>>> >>>>> or false,
>>>>> >>>>> or uninitialized...
>>>>> >>>>> It might be ok to add error or warning macro output, but crashing is
>>>>> >>>>> not
>>>>> >>>>> cool.
>>>>> >>>>
>>>>> >>>> So, here is my experimental dashboard. I can add this to my crontab
>>>>> >>>> until it
>>>>> >>>> is more globally enabled. You can see three tests failing there.
>>>>> >>>>
>>>>> >>>> http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=660272
>>>>> >>>> Marcus
>>>>> >>>> --
>>>>> >>>> Marcus D. Hanwell, Ph.D.
>>>>> >>>> R&D Engineer, Kitware Inc.
>>>>> >>>> (518) 881-4937
>>>>> >>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> François Bertel, PhD  | Kitware Inc. Suite 204
>>> 1 (518) 371 3971 x113 | 28 Corporate Drive
>>>                       | Clifton Park NY 12065, USA
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>
>



More information about the vtk-developers mailing list