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