[vtk-developers] Add GetModifiedTime deprecate GetMTime

[David Cole]

A nice-to-the-user-who-needs-that capability would be to typedef a
type for the return value of GetMTime, and then allow for user
definition of that type. Default to uint64_t, but allow for user
definition.


David C.


On Thu, Aug 4, 2016 at 8:00 AM, Ken Martin <ken.martin at kitware.com> wrote:
> I tend to like that simpler solution as well.  The change is easy to
> explain, the compiler identifies the issues, and fixing them is easy.
> Should the user want to support multiple versions of VTK on Windows (the
> change is a noop on Linux OSX IIRC), an ifdef can be used in the places
> where they override GetMTime to provide the old signature.
>
> Ken
>
>
> On Wed, Aug 3, 2016 at 8:13 PM, David Cole <DLRdave at aol.com> wrote:
>>
>> I agree with Berk: personally, I would prefer a simple change to the
>> signature of GetMTime. Dealing with a documented method signature change
>> when upgrading to a new version of VTK is less annoying than learning a new
>> method name, even a similar one, and partially invalidating years of mailing
>> list discussions about GetMTime (by changing its name)...
>>
>> Again: not a strong preference, though, and will GLADLY use whatever is
>> put into VTK. We have an app that can hit the overflow condition within
>> about 45 minutes when running at full speed, and having a solution where we
>> don't have to have a heavily patched VTK will be awesome.
>>
>> Thanks, Ken, for working on this.
>>
>>
>> David C.
>>
>>
>>
>>
>> On Wednesday, August 3, 2016, Berk Geveci <berk.geveci at kitware.com> wrote:
>>>
>>> Wouldn't it be better to just change the signature of GetMTime() to
>>> return a 64 bit int? Only subclasses would fail to compile. They should be
>>> very easy to fix. Any user of the GetMTime() method would cause a warning
>>> that can be safely ignored by the users of VTK. My personal preference would
>>> be to do that than to cause all users to switch to a new method (over time).
>>> Not a strong preference though.
>>>
>>> On Mon, Aug 1, 2016 at 12:49 PM, Ken Martin <ken.martin at kitware.com>
>>> wrote:
>>>>
>>>>
>>>> I am looking for some feedback here. We have a problem in VTK that on
>>>> Windows unsigned long GetMTime is limited to 32 bits due to the type of
>>>> unsigned long (even on 64 bit builds). This problem creeps up for any VTK
>>>> application that runs for a long time (say 4 hours or more depending on what
>>>> the application is doing). I feel like we need to fix this but from what I
>>>> can see there is no trivially easy fix. Changing the signature of GetMTime
>>>> would break external code that overrides GetMTime. So my thought is to add a
>>>> new method called GetModifiedTime that returns a 64 bit unsigned int.
>>>> Convert VTK to use this method and provide backwards compatibility support
>>>> for external code to still compile/link/and work.
>>>>
>>>> I have created a sample topic here
>>>> https://gitlab.kitware.com/vtk/vtk/merge_requests/1724 that shows the basic
>>>> idea.  In that topic I have not converted over all the other GetMTime calls
>>>> in the VTK tree which I would want to do, rather it is just a topic to show
>>>> the idea behind the change. I believe it handles the common cases properly
>>>> with only one failure case I know of so far (documented in the comments for
>>>> that topic).
>>>>
>>>> If we went with such a change I believe existing code would still work
>>>> unchanged (aside from a warning)
>>>>
>>>> This change would allow external code to have both GetMTime and
>>>> GetModifiedTime so that the external code would work with both old and new
>>>> versions of VTK.
>>>>
>>>> This change will cause some performance issues if VTK_LEGACY_GETMTIME is
>>>> left on. Turning VTK_LEGACY_GETMTIME off would remove the performance cost
>>>> but require external codes to be updated to GetModifiedTime.
>>>>
>>>> It would be nice if I was missing some easy pain free solution here so
>>>> please holler if you see something, have thoughts, etc.
>>>>
>>>> Thanks
>>>> Ken
>>>>
>>>>
>>>> --
>>>> Ken Martin PhD
>>>> Chairman & CFO
>>>> Kitware Inc.
>>>> 28 Corporate Drive
>>>> Clifton Park NY 12065
>>>> 518 371 3971
>>>>
>>>> This communication, including all attachments, contains confidential and
>>>> legally privileged information, and it is intended only for the use of the
>>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>>> not the intended recipient, any disclosure, copying, distribution or any
>>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>>> received this communication in error please notify us immediately and
>>>> destroy the original message.  Thank you.
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.