<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 12, 2015 at 2:13 PM, Ben Boeckel <span dir="ltr"><<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> I have experience doing Lua wrapping for other open source projects, so I'm<br>
> especially confident I could do the former project.<br>
<br>
</span>There is wrapping infrastructure in Wrapping/Tools which does all the<br>
parsing and data extraction already. What would need to be done is to<br>
take those structures and turn them into Lua code to call the right<br>
functions, do type conversions, etc. Extending the wrapping<br>
infrastructure to expose any information Lua needs would be in scope as<br>
well.<br>
<span class=""><br>
> If someone could clarify what people would like to be able do with Lua<br>
<br>
</span>Similar things as Python: take VTK objects, put them into a pipeline,<br>
load data, do computations, etc.<br>
<span class=""><br>
> and which parts of the project would need to be wrapped, that would be<br>
> great.<br>
<br>
</span>If the wrapping infrastructure is used, "all" of VTK shouldn't be too<br>
much past the initial push. There are bound to be corner cases that will<br>
need to be handled though.<br>
<br>
David Gobbi is the main developer behind the wrapping infrastructure,<br>
but I've done some work in it as well.<br></blockquote><div><br></div><div>I can add a bit more info about how the VTK python wrappers work.</div><div>Basically, the wrappers use a custom C++ parser (specifically tuned</div><div>to VTK) that reads all the VTK header files and create a C data structure</div><div>that describes the VTK API in all of its gory detail.  That information is then</div><div>used to generate the python wrapper code for each of the VTK classes.</div><div>The entire python wrapper generator is actually written in C.</div><div><br></div><div>If there is a desire to add other wrapper languages, there are options:</div><div><br></div><div><div>1) I have a modification to the VTK wrappers that generates a full xml</div><div>description of the VTK API at <a href="https://github.com/dgobbi/WrapVTK">https://github.com/dgobbi/WrapVTK</a> ,</div><div>and this xml could be fed into a customized wrapper-code generator. </div></div><div><br></div><div>2) A person could write a back-end for our custom C++ parser that</div><div>generates swig .i files, and then swig can be used to generate the</div><div>language wrappers. Or, the aforementioned xml could be converted</div><div>into a set of .i files for swig.</div><div><br></div><div>3) The same approach could be taken as for the existing wrappers,</div><div>i.e. write the wrapper-generator in C (or C++).  :)</div><div><br></div><div>Due to its complexity, VTK is probably not amenable to off-the-shelf</div><div>wrapping tools.  So just as Qt chose to write their own PySide wrapper</div><div>tools (and Riverbank wrote sip before that), and just as ITK chose to</div><div>use a hybrid gccxml/swig approach, VTK is well served by a customized</div><div>wrapping solution.</div><div><br></div><div> - David</div></div><br></div></div>