Quantcast

ready to branch for 8.0.0?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ready to branch for 8.0.0?

David E DeMarle
Hi,

Does anyone have work in progress that should delay the branch point for
8.0.0?

If so, please add the 8.0.0 milestone on any relevant merge requests
and @mention ben.beockel, demarle, and chuck.atkins so they can be more easily tracked.

We are hoping to get 8.0.0 started by April 3, 2017.

Thanks,

The VTK Maintenance Team

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Cory Quammen-2
Dave,

VTK 8.0.0 seems like a good target for some of the bigger API change
merge requests that have been put off for a while Examples include:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
https://gitlab.kitware.com/vtk/vtk/merge_requests/917

If we are aspiring toward using semantic versioning [1], now would be
the time to make such API changes. And document them nicely as well,
of course.

Thanks,
Cory

[1] http://semver.org/

On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle
<[hidden email]> wrote:

> Hi,
>
> Does anyone have work in progress that should delay the branch point for
> 8.0.0?
>
> If so, please add the 8.0.0 milestone on any relevant merge requests
> and @mention ben.beockel, demarle, and chuck.atkins so they can be more
> easily tracked.
>
> We are hoping to get 8.0.0 started by April 3, 2017.
>
> Thanks,
>
> The VTK Maintenance Team
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>



--
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Ben Boeckel
On Tue, Mar 21, 2017 at 09:24:22 -0400, Cory Quammen wrote:
> If we are aspiring toward using semantic versioning [1], now would be
> the time to make such API changes. And document them nicely as well,
> of course.

If we really want to go with semver, it might be good to get ABI
checkers to check MRs:

    https://lvc.github.io/abi-compliance-checker/

I suspect we'll be bumping major versions every release though unless
we're really diligent about it.

Though the ABI is also affected by all the flags you can set in VTK's
build, so there are other issues since we can't just rely on "it looks
OK", but "it looks OK under configuration X".

--Ben
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Hahn, Steven E.
In reply to this post by Cory Quammen-2
There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double?

Steven

min, max
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58 

isinf
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98

isnan
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56


On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" <[hidden email] on behalf of [hidden email]> wrote:

    Dave,
   
    VTK 8.0.0 seems like a good target for some of the bigger API change
    merge requests that have been put off for a while Examples include:
   
    https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
    https://gitlab.kitware.com/vtk/vtk/merge_requests/917
   
    If we are aspiring toward using semantic versioning [1], now would be
    the time to make such API changes. And document them nicely as well,
    of course.
   
    Thanks,
    Cory
   
    [1] http://semver.org/
   
    On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle
    <[hidden email]> wrote:
    > Hi,
    >
    > Does anyone have work in progress that should delay the branch point for
    > 8.0.0?
    >
    > If so, please add the 8.0.0 milestone on any relevant merge requests
    > and @mention ben.beockel, demarle, and chuck.atkins so they can be more
    > easily tracked.
    >
    > We are hoping to get 8.0.0 started by April 3, 2017.
    >
    > Thanks,
    >
    > The VTK Maintenance Team
    >
    > David E DeMarle
    > Kitware, Inc.
    > R&D Engineer
    > 21 Corporate Drive
    > Clifton Park, NY 12065-8662
    > Phone: 518-881-4909
    >
    > _______________________________________________
    > Powered by www.kitware.com
    >
    > Visit other Kitware open-source projects at
    > http://www.kitware.com/opensource/opensource.html
    >
    > Search the list archives at: http://markmail.org/search/?q=vtk-developers
    >
    > Follow this link to subscribe/unsubscribe:
    > http://public.kitware.com/mailman/listinfo/vtk-developers
    >
    >
   
   
   
    --
    Cory Quammen
    Staff R&D Engineer
    Kitware, Inc.
    _______________________________________________
    Powered by www.kitware.com
   
    Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
   
    Search the list archives at: http://markmail.org/search/?q=vtk-developers
   
    Follow this link to subscribe/unsubscribe:
    http://public.kitware.com/mailman/listinfo/vtk-developers
   
   
   

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

David Gobbi
Not clear what you mean here.  Do you want to template the IsInf, IsNan, and IsFinite methods in vtkMath, or do you want to VTK codebase to stop using them?


On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. <[hidden email]> wrote:
There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double?

Steven

min, max
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58

isinf
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98

isnan
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56


On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" <[hidden email] on behalf of [hidden email]> wrote:

    Dave,

    VTK 8.0.0 seems like a good target for some of the bigger API change
    merge requests that have been put off for a while Examples include:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
    https://gitlab.kitware.com/vtk/vtk/merge_requests/917

    If we are aspiring toward using semantic versioning [1], now would be
    the time to make such API changes. And document them nicely as well,
    of course.

    Thanks,
    Cory

    [1] http://semver.org/

    On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle
    <[hidden email]> wrote:
    > Hi,
    >
    > Does anyone have work in progress that should delay the branch point for
    > 8.0.0?
    >
    > If so, please add the 8.0.0 milestone on any relevant merge requests
    > and @mention ben.beockel, demarle, and chuck.atkins so they can be more
    > easily tracked.
    >
    > We are hoping to get 8.0.0 started by April 3, 2017.
    >
    > Thanks,
    >
    > The VTK Maintenance Team
    >
    > David E DeMarle
    > Kitware, Inc.
    > R&D Engineer
    > 21 Corporate Drive
    > Clifton Park, NY 12065-8662
    > Phone: 518-881-4909

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

David Gobbi
Typo: I meant to write "want the VTK codebase to stop using them".

On Tue, Mar 21, 2017 at 9:03 AM, David Gobbi <[hidden email]> wrote:
Not clear what you mean here.  Do you want to template the IsInf, IsNan, and IsFinite methods in vtkMath, or do you want to VTK codebase to stop using them?


On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. <[hidden email]> wrote:
There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double?

Steven

min, max
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58

isinf
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98

isnan
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56


On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" <[hidden email] on behalf of [hidden email]> wrote:

    Dave,

    VTK 8.0.0 seems like a good target for some of the bigger API change
    merge requests that have been put off for a while Examples include:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
    https://gitlab.kitware.com/vtk/vtk/merge_requests/917

    If we are aspiring toward using semantic versioning [1], now would be
    the time to make such API changes. And document them nicely as well,
    of course.

    Thanks,
    Cory

    [1] http://semver.org/

    On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle
    <[hidden email]> wrote:
    > Hi,
    >
    > Does anyone have work in progress that should delay the branch point for
    > 8.0.0?
    >
    > If so, please add the 8.0.0 milestone on any relevant merge requests
    > and @mention ben.beockel, demarle, and chuck.atkins so they can be more
    > easily tracked.
    >
    > We are hoping to get 8.0.0 started by April 3, 2017.
    >
    > Thanks,
    >
    > The VTK Maintenance Team
    >
    > David E DeMarle
    > Kitware, Inc.
    > R&D Engineer
    > 21 Corporate Drive
    > Clifton Park, NY 12065-8662
    > Phone: <a href="tel:(518)%20881-4909" value="+15188814909" target="_blank">518-881-4909


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Hahn, Steven E.

The former. I’d like to move these functions (and workarounds for certain data types and compilers) into a header where they can be reused. Would it make sense to either template the existing function in vtkMath or put the templated functions in a different header file?

 

From: David Gobbi <[hidden email]>
Date: Tuesday, March 21, 2017 at 11:04 AM
To: "Hahn, Steven E." <[hidden email]>
Cc: vtkdev <[hidden email]>
Subject: Re: [vtk-developers] ready to branch for 8.0.0?

 

Typo: I meant to write "want the VTK codebase to stop using them".

 

On Tue, Mar 21, 2017 at 9:03 AM, David Gobbi <[hidden email]> wrote:

Not clear what you mean here.  Do you want to template the IsInf, IsNan, and IsFinite methods in vtkMath, or do you want to VTK codebase to stop using them?

 

 

On Tue, Mar 21, 2017 at 8:31 AM, Hahn, Steven E. <[hidden email]> wrote:

There are templated min, max, isinf, and isnan functions scattered around the VTK codebase. Is this a good time to replace the (slower?) functions in vtkMath.h that require a conversion to double?

Steven

min, max
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L58

isinf
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkDataArrayPrivate.txx#L98

isnan
https://gitlab.kitware.com/vtk/vtk/blob/3c479cfe4ab201f74642ef0973ae65ebb96dcab2/Common/Core/vtkGenericDataArrayLookupHelper.h#L56



On 3/21/17, 9:24 AM, "vtk-developers on behalf of Cory Quammen" <[hidden email] on behalf of [hidden email]> wrote:

    Dave,

    VTK 8.0.0 seems like a good target for some of the bigger API change
    merge requests that have been put off for a while Examples include:

    https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
    https://gitlab.kitware.com/vtk/vtk/merge_requests/917

    If we are aspiring toward using semantic versioning [1], now would be
    the time to make such API changes. And document them nicely as well,
    of course.

    Thanks,
    Cory

    [1] http://semver.org/

    On Mon, Mar 20, 2017 at 5:39 PM, David E DeMarle
    <[hidden email]> wrote:
    > Hi,
    >
    > Does anyone have work in progress that should delay the branch point for
    > 8.0.0?
    >
    > If so, please add the 8.0.0 milestone on any relevant merge requests
    > and @mention ben.beockel, demarle, and chuck.atkins so they can be more
    > easily tracked.
    >
    > We are hoping to get 8.0.0 started by April 3, 2017.
    >
    > Thanks,
    >
    > The VTK Maintenance Team
    >
    > David E DeMarle
    > Kitware, Inc.
    > R&D Engineer
    > 21 Corporate Drive
    > Clifton Park, NY 12065-8662
    > Phone: <a href="tel:(518)%20881-4909" target="_blank">518-881-4909

 


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Marcus D. Hanwell-2
On Tue, Mar 21, 2017 at 11:41 AM, Hahn, Steven E. <[hidden email]> wrote:
> The former. I’d like to move these functions (and workarounds for certain
> data types and compilers) into a header where they can be reused. Would it
> make sense to either template the existing function in vtkMath or put the
> templated functions in a different header file?
>
vtkMathUtilities.h in Common/Core would be a good place, I started it
to put more modern, inline and/or templated functions in.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Sean McBride
In reply to this post by Hahn, Steven E.
On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said:

>The former. I’d like to move these functions (and workarounds for
>certain data types and compilers) into a header where they can be
>reused. Would it make sense to either template the existing function in
>vtkMath or put the templated functions in a different header file?

Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf.

Cheers,

Sean
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Cory Quammen-2
In reply to this post by Ben Boeckel
On Tue, Mar 21, 2017 at 10:10 AM, Ben Boeckel <[hidden email]> wrote:

> On Tue, Mar 21, 2017 at 09:24:22 -0400, Cory Quammen wrote:
>> If we are aspiring toward using semantic versioning [1], now would be
>> the time to make such API changes. And document them nicely as well,
>> of course.
>
> If we really want to go with semver, it might be good to get ABI
> checkers to check MRs:
>
>     https://lvc.github.io/abi-compliance-checker/
>
> I suspect we'll be bumping major versions every release though unless
> we're really diligent about it.
>
> Though the ABI is also affected by all the flags you can set in VTK's
> build, so there are other issues since we can't just rely on "it looks
> OK", but "it looks OK under configuration X".

I think ABI-backwards compatibility is probably a little pie in the
sky for VTK. An API compatibility checker for MRs would be great. Let
the buildbot be the curmudgeon, I say.

Cory

--
Cory Quammen
Staff R&D Engineer
Kitware, Inc.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Hahn, Steven E.
In reply to this post by Sean McBride
I've encountered a few complications with recent versions of MSVC and clang with integral value types.  With std::isnan and std::isinf Visual Studio 2017 generates an error message. With std::isinf<int> clang generates code that is 3-4 times slower than one would naively expect for a type that doesn’t contain infinity. I worked around both issues with tag dispatch, but don’t think we want that code copied and pasted throughout the VTK codebase.

Steven
________________________________________
From: Sean McBride <[hidden email]>
Sent: Wednesday, March 22, 2017 5:01 PM
To: Hahn, Steven E.; David Gobbi
Cc: vtkdev
Subject: Re: [vtk-developers] ready to branch for 8.0.0?

On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said:

>The former. I’d like to move these functions (and workarounds for
>certain data types and compilers) into a header where they can be
>reused. Would it make sense to either template the existing function in
>vtkMath or put the templated functions in a different header file?

Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf.

Cheers,

Sean



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Robert Maynard-4
Given these issues, and known performance problems with
std::min/std::max I think it would be valuable to provide a single
header that wraps all these functions and provides fast versions where
needed. Personally I see no reason to not place these into a vtk
namespace.

On Thu, Mar 23, 2017 at 10:07 AM, Hahn, Steven E. <[hidden email]> wrote:

> I've encountered a few complications with recent versions of MSVC and clang with integral value types.  With std::isnan and std::isinf Visual Studio 2017 generates an error message. With std::isinf<int> clang generates code that is 3-4 times slower than one would naively expect for a type that doesn’t contain infinity. I worked around both issues with tag dispatch, but don’t think we want that code copied and pasted throughout the VTK codebase.
>
> Steven
> ________________________________________
> From: Sean McBride <[hidden email]>
> Sent: Wednesday, March 22, 2017 5:01 PM
> To: Hahn, Steven E.; David Gobbi
> Cc: vtkdev
> Subject: Re: [vtk-developers] ready to branch for 8.0.0?
>
> On Tue, 21 Mar 2017 15:41:00 +0000, Hahn, Steven E. said:
>
>>The former. I’d like to move these functions (and workarounds for
>>certain data types and compilers) into a header where they can be
>>reused. Would it make sense to either template the existing function in
>>vtkMath or put the templated functions in a different header file?
>
> Maybe our new minimum compiler requirements would finally allow us to just use std::isnan, std::isfinite, and std::isinf.
>
> Cheers,
>
> Sean
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Aashish Chaudhary-2
In reply to this post by David E DeMarle
We have one or two volume branches which we are hoping to get merged this week is desired for 8.0. I will tag them today. 

Thanks,


On Mon, Mar 20, 2017 at 5:40 PM David E DeMarle <[hidden email]> wrote:
Hi,

Does anyone have work in progress that should delay the branch point for
8.0.0?

If so, please add the 8.0.0 milestone on any relevant merge requests
and @mention ben.beockel, demarle, and chuck.atkins so they can be more easily tracked.

We are hoping to get 8.0.0 started by April 3, 2017.

Thanks,

The VTK Maintenance Team

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: <a href="tel:(518)%20881-4909" value="+15188814909" class="gmail_msg" target="_blank">518-881-4909
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Sean McBride
In reply to this post by Hahn, Steven E.
On Thu, 23 Mar 2017 14:07:03 +0000, Hahn, Steven E. said:

>With std::isinf<int> clang generates code that is 3-4 times slower than
>one would naively expect for a type that doesn’t contain infinity.

Is there a bug for that?  A quick search didn't reveal anything:

<https://bugs.llvm.org//buglist.cgi?quicksearch=isinf>

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Hahn, Steven E.
I sent a message along with a short file showing the performance bug to the cfe-dev mailing list but haven’t received a response.

http://lists.llvm.org/pipermail/cfe-dev/2017-March/053305.html

On 3/27/17, 5:11 PM, "Sean McBride" <[hidden email]> wrote:

    On Thu, 23 Mar 2017 14:07:03 +0000, Hahn, Steven E. said:
   
    >With std::isinf<int> clang generates code that is 3-4 times slower than
    >one would naively expect for a type that doesn’t contain infinity.
   
    Is there a bug for that?  A quick search didn't reveal anything:
   
    <https://bugs.llvm.org//buglist.cgi?quicksearch=isinf>
   
    Cheers,
   
    --
    ____________________________________________________________
    Sean McBride, B. Eng                 [hidden email]
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
   

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Sean McBride
In reply to this post by Cory Quammen-2
On Tue, 21 Mar 2017 09:24:22 -0400, Cory Quammen said:

>VTK 8.0.0 seems like a good target for some of the bigger API change
>merge requests that have been put off for a while Examples include:
>
>https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
>https://gitlab.kitware.com/vtk/vtk/merge_requests/917
>
>If we are aspiring toward using semantic versioning [1], now would be
>the time to make such API changes. And document them nicely as well,
>of course.

Even though I authored those MRs, it seems to me too late to merge them since the 8.0 branch is imminent.  Maybe after 8.0 is branched, they could be merged to master?  Will an eventual 8.0.1 or 8.1 come from master or the 8.0 branch?  It is indeed not clear when such breaking changes can actually get merged...

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

David E DeMarle
Apologies for not saying so earlier but I'm going to delay 8.0 to give people time to make the changes mentioned in this thread and because the project that requested it slackened. I'm now aiming for a May 1st branch.

8.0.1 will come from the 8.0.0 tag (at that point aka release branch) and only if important bugs turn up in 8.0.0.

8.1 will come from master a few months down the road.

On Thursday, April 6, 2017, Sean McBride <[hidden email]> wrote:
On Tue, 21 Mar 2017 09:24:22 -0400, Cory Quammen said:

>VTK 8.0.0 seems like a good target for some of the bigger API change
>merge requests that have been put off for a while Examples include:
>
>https://gitlab.kitware.com/vtk/vtk/merge_requests/1455
>https://gitlab.kitware.com/vtk/vtk/merge_requests/917
>
>If we are aspiring toward using semantic versioning [1], now would be
>the time to make such API changes. And document them nicely as well,
>of course.

Even though I authored those MRs, it seems to me too late to merge them since the 8.0 branch is imminent.  Maybe after 8.0 is branched, they could be merged to master?  Will an eventual 8.0.1 or 8.1 come from master or the 8.0 branch?  It is indeed not clear when such breaking changes can actually get merged...

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 <a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;sean@rogue-research.com&#39;)">sean@...
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada




--
David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ready to branch for 8.0.0?

Isaiah Norton
In reply to this post by Sean McBride
On Mon, Mar 27, 2017 at 5:11 PM, Sean McBride <[hidden email]> wrote:
On Thu, 23 Mar 2017 14:07:03 +0000, Hahn, Steven E. said:

>With std::isinf<int> clang generates code that is 3-4 times slower than
>one would naively expect for a type that doesn’t contain infinity.

Is there a bug for that?  A quick search didn't reveal anything:

This is the same underlying issue as:

libc++ interpreted the standard in a way that doesn't make sense, such that any isinf and isnan arguments are cast to double (this makes no sense because the Inf bit pattern is a perfectly valid integer much smaller than the typemax).

Whereas libstdc++ only defines std::isinf for float/double/long double, and all other types are a constexpr false.


<https://bugs.llvm.org//buglist.cgi?quicksearch=isinf>

Cheers,

--
____________________________________________________________
Sean McBride, B. Eng                 [hidden email]
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Loading...