[vtk-developers] Tcl wrapping and output array arguments
Andrew Maclean
andrew.amaclean at gmail.com
Fri Mar 20 19:38:57 EDT 2015
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
___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150321/4dd8bb93/attachment-0001.html>
-------------- next part --------------
VTK 6.0
All the cxx examples converted Ok.
For the python conversions:
1) Added a new file colors.py from VTK\Wrapping\Python\vtk\util\colors.py
2) Added a file called: WindowLevelInterface.py to provide sliders.
T: Converted to Tcl for Vtk 6.0
P: Converted to Python for VTK 6.0
T P 3dsToRIB
T P animVectors
T P *Attenuation: Converted Ok, however for the Python version, an extra file WindowLevelInterface.py provides sliders to manipulate the image.
T P blow
############# Frog ################
T P segmented8, SliceOrder
blood, brain, brainbin, frog, duodenum, eye_retna.ttcl, eye_white
heart, ileum, kidney, l_intestine, liver, lung, nerve,
skeleton, spleen, stomach
For Python: blood, brain, brainbin, frog, duodenum, eye_retna.ttcl, eye_white
heart, ileum, kidney, l_intestine, liver, lung, nerve,
skeleton, spleen, stomach
were converted to text files.
The parameters were rationalised, eliminating duplicate parameters.
segmented8.py has been rewritten to so that the *.txt files are read in as parameter files,
blood.txt and frog.txt are used if no parameter files are specified.
In segmented8.py vtkDecimatePro is used instead of vtkDecimate which gives different results.
Default values are provided for the parameters and checks are made for required parameters.
T P marching8, SliceOrder, skin
For Python: skin has been converted to a test file.
T P- renactors - renders all the vtk files created by segmented8 and marching8
- P BuildFrog.py - builds and renders all the tissues of the frog.
T P FrogSlice Not working yet for Python.
###################################
T P bluntStr - Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader.
T P bottle
T P CamBlur - Converted Ok, the writer now uses vtkPNGWriter
T P camera
T P camera2
T P clipPlane
T P clipSphCyl
T P ColorSph
T P combIso
T P complexV
T P Cone
T P Cone2
T P connPineRoot
T P createBFont
T P cut Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader.
T P cutModel
T P cutPlane
T - dcubes: Used the patented vtkDividingCubes replaced with vtkRecursiveDividingCubes.
T P deciFran
T P deciHawa
T - **Decimate
T P deciPineRoot
T P DelMesh
- - *EnhanceEdges: Not converted
T P expCos
T P extractD
T P flamingo
T - frogLut
T - frogSlice
- - *GaussianSmooth
T P hawaii
T P headBone
T P headSlic
T P hello
T - *HybridMedianComparison, ShotNoiseInclude
T P Hyper
T P IdealHighPass
T P imageWarp
T P ironPIso
T P IsoSubsample
T P LineWidget Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader.
T P LOx
T P LOxGrid
T P Mace
T - *MedianComparison, ShotNoiseInclude
T P MotBlur
T P motor
T P Normals
T P office
T P officeTube
- - opacity - sets opacity for the frog
T - *Pad
T P pickCells
T P probe
T P probeComb
T P quadricCut
T P rainbow Converted vtkPlot3DReader to vtkMultiBlockPLOT3DReader. Added in an example of using a colour transfer function.
T P smoothCyl
T P sphere
T P splatFace
T P spring
T P stocks
T P streamV
T P stripF
- - sweptVtk vtkSweptSurface is patented. It has been converted but not tested. I don't know of a relacement for vtkSweptSurface.
T P tcutSph
T P TenEllip
T P thrshldV
T P TPlane
T P uStripeF
T - WindowLevel
* vtkTkImageViewerWidget not there
** vtkTkRenderWidget not there
More information about the vtk-developers
mailing list