[vtk-developers] Tcl wrapping and output array arguments

Fri Mar 20 20:45:05 EDT 2015

When the topic came up on the ARB (back in 2011!) I sent the note quoted
below about how we handle this in Slcer4.  There is one project
(EMSegmenter) that still uses 'tpycl' method discussed below.  Everything
else has been ported.  While it's unconventional, it does work fine and
allows people to write good old tcl code even though their vtk is only
wrapped for python.  It's kinda magical really, and could be used to solve
Berk's book concerns

-Steve

p.s. over beer sometime, just to prove I'm really a crazy old coot, I'll be
happy to take the position that python for all it's admitted utility, is
still missing many cool features that made tcl especially productive.

Hi Guys -

As one of the olde timey tcl guys, I'd agree with Andrew's assessment that
supporting tcl in the future is not required and should be considered for
the chopping block for VTK 6.

FWIW, the current development version of slicer (version 4, to be released
this year) relies only on the vtk python wrappings.  For most purposes, the
differences between python and tcl are pretty minimal - but the big thing
python has is numpy and the ability to get at image/poly data as numpy
arrays.  Now with SimplyITK's python bindings it is becoming possible to
move bulk data around between packages in very nice ways.

For those who are interested, the last vestiges of tcl in slicer are
supported by an adapter layer which uses tkinter and a custom package
called tpycl (python inside tcl - meant to be pronounced, with a sigh and a
roll of the eyes as "typical!").  With typcl, big chunks of slicer code
written for tcl wrapped vtk can be run unchanged against a python wrapped
vtk.  This is used to delay the task of porting/debugging legacy the Editor
and the EMSegmenter.

http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Base/Python/tpycl/

This layer is for backwards compatibility only - nobody is using it for new
development.

-Steve

On Fri, Mar 20, 2015 at 8:34 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> I checked with Steve Pieper (Slicer guru). He does not care if tcl goes
> away…
>
> Personally, I don't care. In fact I wouldn't care if we dropped java and
> python.
>
> Code coverage is a concern, but that can be fixed if the tcl tests are
> all converted.
>
>
> On Fri, Mar 20, 2015 at 5:24 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> > I am not against this either but I'd like to remind people that there
> are 2
> > VTK books that still use Tcl for their examples. We probably need to
> figure
> > out how to transition those before discontinuing Tcl support.
> >
> > -berk
> >
> >
> > On Fri, Mar 20, 2015 at 8:21 PM, Will Schroeder <
> will.schroeder at kitware.com>
> > wrote:
> >>
> >> Personally I have no real attachment to Tcl and can see queuing it up
> for
> >> deprecation at some point. I'd like to get the community more widely
> >> involved in this decision in terms of when, etc. since there may be some
> >> significant applications out there still using it and we want to
> minimize
> >> community disruption. There's a lot going on now anyway with the gitlab
> and
> >> OpenGL2 changes so this is not likely to happen anytime soon.
> >>
> >> W
> >>
> >> W
> >>
> >> On Fri, Mar 20, 2015 at 7:38 PM, Andrew Maclean
> >> <andrew.amaclean at gmail.com> wrote:
> >>>
> >>> David, David, Will, John
> >>>
> >>> I remember the TCL discussion, maybe the time has come to raise
> dropping
> >>> it again. I would certainly support that. It was useful before Python
> was
> >>> widely used but nowadays I think C++/Python/Java programmers would
> rarely
> >>> (if ever) need to use it. Personally I find it difficult to understand
> and
> >>> use.It is not a modern language,
> >>>
> >>> One of the reasons TCL was useful in the "old days" was that a lot of
> the
> >>> testing code was written in it but that is hardly relevant now since we
> >>> converted almost all of it into Python.
> >>>
> >>> Will, I did translate most of the VTK Textbook exercises into Python
> soon
> >>> after that discussion (way back in 2012). There were a couple that I
> >>> couldn't convert, see the attached document for a summary of what I
> have
> >>> done.
> >>>
> >>> I'll look at converting TestSetGet and TestEmptyInput to python.
> >>>
> >>> Regards
> >>>    Andrew
> >>>
> >>>>
> >>>>
> >>>> ---------- Forwarded message ----------
> >>>> From: David Lonie <david.lonie at kitware.com>
> >>>> To: David Gobbi <david.gobbi at gmail.com>
> >>>> Cc: VTK Developers <vtk-developers at vtk.org>
> >>>> Date: Fri, 20 Mar 2015 09:00:01 -0400
> >>>> Subject: Re: [vtk-developers] Tcl wrapping and output array arguments
> >>>> 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:
> >>>>>>
> >>>>>>
> >>>>>> My questions:
> >>>>>>
> >>>>>> 1) Is the concept of an "output array argument" even supported by
> Tcl?
> >>>>>
> >>>>>
> >>>>> Yes.  I imagine something like this could create a new array called
> >>>>> "bounds":
> >>>>>
> >>>>>   % mapper GetBounds renderer bounds
> >>>>>
> >>>>>>
> >>>>>> 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.  I believe that Tcl will already
> wrap
> >>>>> this method, but the wrapped method will expect 6 values as input,
> instead
> >>>>> of expecting one name for an output array that it should create.
> Because
> >>>>> the wrappers can't really tell whether "double[6]" is meant to be
> used for
> >>>>> input or output, the method will actually have to be wrapped twice,
> once for
> >>>>> input, and once for output.  There are undoubtedly some tricky
> complications
> >>>>> that I haven't though of, however.
> >>>>
> >>>>
> >>>> Unfortunately, the method is not wrapped currently (according to the
> >>>> generated vtkPropTcl.cxx file, anyway).
> >>>>
> >>>>>> And perhaps the most curious question from my point of view,
> >>>>>>
> >>>>>> 4) Why do we still provide Tcl bindings in 2015?
> >>>>>
> >>>>>
> >>>>> Because they're cool!  Actually, at this point I'm fine with them
> going
> >>>>> away, but I'd still like to keep Tkinter (which works just fine
> without the
> >>>>> Tcl wrappers).
> >>>>
> >>>>
> >>>> The general consensus from the developers I've talked to out here is
> the
> >>>> same -- we'd love to see Tcl go. I had a heck of a time trying to
> even find
> >>>> a developer who remembered enough about Tcl to begin tracking down
> this
> >>>> issue before I posted on the mailing list...and this includes the
> people who
> >>>> wrote the original Tcl wrappers ;)
> >>>>
> >>>>>>
> >>>>>> But seriously, can we deprecate them for 6.3?
> >>>>>
> >>>>>
> >>>>> Any volunteers to convert TestSetGet and TestEmptyInput to python?
> >>>>
> >>>>
> >>>> Looks like Andrew has volunteered :D
> >>>>
> >>>> I found this discussion from around v6.0's release:
> >>>>
> >>>>
> >>>>
> http://vtk.1045678.n5.nabble.com/Modularization-Context2D-and-Tcl-td5594211.html
> >>>>
> >>>> Looks like there was a fair bit of resistance against dropping Tcl 2-3
> >>>> years ago, so I'm not sure how worthwhile it would be to push for
> this now.
> >>>>
> >>>> But if supporting such a simple method like this requires "more than
> an
> >>>> afternoon's work" to teach Tcl to understand it, it sounds like more
> of a
> >>>> burden than a benefit. From what I'm seeing, it's a non-trivial
> amount of
> >>>> work to keep Tcl working with new APIs and few active developers
> actually
> >>>> remember Tcl well enough to work on it. Not to mention that in my few
> years
> >>>> here at Kitware, I've never actually come across an active project
> that uses
> >>>> Tcl -- not to say they don't exist, but they seem quite rare these
> days.
> >>>>
> >>>> In any case, decisions like these are beyond me. I'm just a C++ guy
> >>>> trying to add a simple new method to the library :-)
> >>>>
> >>>> Dave
> >>>>
> >>>
> >>> --
> >>> ___________________________________________
> >>> Andrew J. P. Maclean
> >>>
> >>> ___________________________________________
> >>
> >>
> >>
> >>
> >> --
> >> William J. Schroeder, PhD
> >> Kitware, Inc.
> >> 28 Corporate Drive
> >> Clifton Park, NY 12065
> >> will.schroeder at kitware.com
> >> http://www.kitware.com
> >> (518) 881-4902
> >>
> >> _______________________________________________
> >> 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
> >
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> 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/20150320/88b49e45/attachment-0001.html>