[vtk-developers] Dashboard test failure question
David E DeMarle
dave.demarle at kitware.com
Fri Jan 17 14:29:15 EST 2014
I marked it as fixed because I was told it was and because the dashboard
stopped showing the issue at about the right time.
Won't fix or Open are fine by me and I lean toward open. In any case Fixed
is definitely not right! My fault sorry about that.
David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
On Fri, Jan 17, 2014 at 2:24 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> I understand. However, if the bug isn't fixed and there is a very low
> probability that it every will be fixed, it should be marked as "won't fix"
> instead of being marked as "fixed".
>
> So I'm just wondering how it came to pass that the bug is marked as
> fixed, when it isn't.
>
> David
>
>
> On Fri, Jan 17, 2014 at 12:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> > I'm pretty sure that did not fix the bug.
> >
> > We spent a lot of time on this one. The volume rendering code is old
> > and tough to follow.
> >
> >
> >
> > On Fri, Jan 17, 2014 at 1:38 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >> I went back to the bug report on this multi-threading issue, and oddly
> >> enough the bug is marked as "fixed":
> >> http://www.vtk.org/Bug/view.php?id=13420
> >>
> >> A note in the bug report says "Was fixed in commit: e4a793c47cc3"
> >> But I looked at the commit, and it seems to be unrelated. Why was
> >> the bug closed, when the problem still exists? Was it closed
> >> accidentally?
> >>
> >> David
> >>
> >>
> >> On Fri, Jan 17, 2014 at 10:40 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>> On Fri, Jan 17, 2014 at 10:07 AM, David Cole <dlrdave at aol.com> wrote:
> >>>>
> >>>> If that warning is true, then shouldn't any test that uses that class
> set
> >>>> the number of threads to 1 instead of trying to use all the cores
> available
> >>>> on a machine......?
> >>>
> >>> Bill already fixed a bunch of tests to set NumberOfThreads=1 for this
> >>> mapper. TestSmartVolumeMapperWindowLevel must have slipped through
> >>> the cracks.
> >>>
> >>>> Does anybody really want non-repeatable results?
> >>>
> >>> Fixing the bug in the mapper would be the correct way of ensuring
> >>> repeatable results: it's a multi-threaded mapper, but running it
> >>> with too many threads causes artifacts. In my view, the
> >>> "SetNumberOfThreads(1)" trick is a way of sweeping the problem
> >>> under the rug, out of sight and out of mind.
> >>>
> >>> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140117/8f10ed77/attachment-0002.html>
More information about the vtk-developers
mailing list