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

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

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