[vtk-developers] Tcl wrapping and output array arguments

[Jorge Perez]

Hello, we are developing some applications based on VTK + Tcl. For our
requirements, we think this a very productive multi-platform solution and
we would like to provide support to solve the issue here raised with the
aim to continue the development of the Tcl Wrapping capabilities in VTK. In
order to help in this issue we appreciate any guide to understand the
arguments that vtkWrapTcl is processing.

best regards,

Jorge

2015-03-23 16:18 GMT+01:00 David Lonie <david.lonie at kitware.com>:

> 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/c1484fdd/attachment.html>