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