[vtk-developers] Tcl wrapping and output array arguments

Berk Geveci berk.geveci at kitware.com
Mon Mar 23 12:54:46 EDT 2015


+1 to (3).

-berk

On Mon, Mar 23, 2015 at 11:18 AM, David Lonie <david.lonie at kitware.com>
wrote:

> On Fri, Mar 20, 2015 at 9:42 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> On Fri, Mar 20, 2015 at 7:17 AM, David Lonie <david.lonie at kitware.com>
>> wrote:
>>
>>> On Thu, Mar 19, 2015 at 5:54 PM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>>
>>>> On Thu, Mar 19, 2015 at 2:28 PM, David Lonie <david.lonie at kitware.com>
>>>> wrote:
>>>>
>>>>> 2) If so, how can I teach the wrappers about it?
>>>>>
>>>>
>>>> Adding things like this to Tcl is easier than for Java or Python, but
>>>> it's more than an afternoon's work.
>>>>
>>>
>>> One more thing:
>>>
>>> If you know offhand, can you briefly outline the steps that are needed
>>> to do this? That might help clarify whether the maintenance burden is
>>> excessive or not. Would it be a one-time deal that would teach Tcl how to
>>> wrap all similar methods, or would it need to be repeated for every similar
>>> method that gets added?
>>>
>>
>> My brief outline is this: find the code in vtkWrapTcl.c that builds
>> arrays to be used as return values, and then do something similar for this
>> new kind of method signature, except have it assign a global name (whatever
>> name was passed as a parameter) to the new array instead of returning it.
>> If it is done for this method, it should work for all similar methods.
>>
>
> This seems more doable than I'd feared, since it'd be a generic approach
> that should "just work" for similar cases.
>
> It sounds like there's a lot of support for removing Tcl, but it's
> unlikely that we'll see it go away completely anytime soon for a multitude
> of reasons. So back to the immediate issue of how the GetBounds change can
> be made to work with the wrappers, I see three options:
>
> 1) Train the wrappers to understand it. Might not be worth the effort if
> we're planning to pull support soon.
>
> 2) Add an additional non-deprecated GetBounds signature
>
> double* GetBounds(vtkViewport*)
>
> I don't like this approach as it has issues thread safety, and requires
> each object to carry around an array just to pass results back to a caller
> -- a pattern we should be moving away from. I'd be more supportive of this
> approach if we decided to use vtkTuple<double, 6> instead of double*, but
> this would also be likely to require some significant wrapper training
> and/or concrete vtkTuple subclasses.
>
> 3) Begin a long-term deprecation of Tcl. We'll not plan on removing it
> completely anytime soon, but enabling Tcl wrapping will also require
> enabling legacy code in VTK. This way the old legacy GetBounds, etc
> signatures will still be available to Tcl, and feedback from the
> deprecation would help us understand the full impact of completely removing
> Tcl, as we'll grab the attention of users that might not follow the mailing
> lists.
>
> My vote is for 3 -- it's an easy change that gives people a heads-up about
> then inevitable future removal of Tcl support, and ensures that everything
> will "just work" for legacy code until we decide to completely pull the
> plug.
>
> Thoughts? Votes? Alternatives?
>
> Dave
>
> _______________________________________________
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150323/8f6784fe/attachment.html>


More information about the vtk-developers mailing list