Hi David,<div><br></div><div>As part of the testing to get your wrapping stuff merged, we built on Windows 64 bit and ran into some trouble.</div><div><br></div><div>The first was a crash during vtkWrapPython that was just an uninitialized variable.  The fix can be seen at</div>
<div><br></div><div><a href="http://github.com/keith-fieldhouse/VTK/commit/c6d900">http://github.com/keith-fieldhouse/VTK/commit/c6d900</a></div><div><br></div><div><a href="http://github.com/keith-fieldhouse/VTK/commit/c6d900"></a>If you&#39;re interested.</div>
<div><br></div><div>The other is a little more troublesome and I&#39;m hoping you can help me understand it.  I&#39;m getting random failures during vtkWrapJava under Visual Studio.  The failures manifest themselves differently depending on how things are run (things proceed normally under nmake, but crash under Visual Studio for example) which leads to the suspicion of some sort of memory error.</div>
<div><br></div><div>Valgrind under 64bit Linux provides a clue.  One of the files that tends to fail wrapping is Common/vtkMatrix4x4.h while Common/vtkMatrix3x3.h hasn&#39;t exhibited a failure.  Comparing the valgrind output for the two files suggests the following.</div>
<div><br></div><div>In vtkParse.l after commit 047dc6ca  the LPAREN_POINTER stanza looks like this:</div><div><br></div><div><span class="Apple-style-span" style="font-family: helvetica, arial, freesans, clean, sans-serif; font-size: 11px; line-height: 14px; "><pre style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; font: normal normal normal 12px/normal Monaco, &#39;Courier New&#39;, &#39;DejaVu Sans Mono&#39;, &#39;Bitstream Vera Sans Mono&#39;, monospace; line-height: 1.4em; font-family: &#39;Bitstream Vera Sans Mono&#39;, Courier, monospace; font-size: 12px; ">
<div class="line" id="LC346" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: rgb(255, 255, 204); ">
&quot;(&quot;[\t\n\r ]*([a-zA-Z_][a-zA-Z0-9_]*::)*&quot;*&quot; {</div><div class="line" id="LC347" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                int i = 1;</div><div class="line" id="LC348" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                int j;</div><div class="line" id="LC349" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                while (yytext[i]==&#39; &#39; || yytext[i]==&#39;\t&#39; ||</div><div class="line" id="LC350" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                       yytext[i]==&#39;\r&#39; || yytext[i]==&#39;\n&#39;) { i++; }</div><div class="line" id="LC351" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                i++; j = i;</div><div class="line" id="LC352" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                while (yytext[j]!=&#39;*&#39;) { j++; }</div><div class="line" id="LC353" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                yylval.str = (char *)malloc(j-i+1);</div><div class="line" id="LC354" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                if (j &gt; i) { strncpy(yylval.str, &amp;yytext[i], j-i); }</div><div class="line" id="LC355" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                yylval.str[j-i] = &#39;\0&#39;;</div><div class="line" id="LC356" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                return(LPAREN_POINTER);</div><div class="line" id="LC357" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 1em; line-height: 1.4em; background-color: transparent; ">
                }</div></pre></span></div><div><br></div><div>Valgrind emits a number of errors that suggest that in the while(yytext[j]!=&#39;*&#39;), A &#39;*&#39; is never found and j gets incremented beyond the bounds of yytext and hijinx ensue.    While I&#39;m not certain that this is causing the crashes I&#39;m seeing, it is suggestive.  My experience with Lex dates back more years than I care to think about so I&#39;m not entirely sure why you&#39;re looking for another &#39;*&#39; here?  Or maybe I&#39;m just misreading the code entirely, which is why I&#39;m asking for your help. Does my analysis make sense and is there an approach you can see that would eliminate the problem?</div>
<div><br></div><div>Thanks again for all of your help.</div><div><br></div><div>Keith</div><div><br><br><div class="gmail_quote">On Fri, May 28, 2010 at 12:48 PM, David Gobbi <span dir="ltr">&lt;<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Marcus,<br>
<br>
If you can get it merged by next week, that would be great.<br>
<br>
>From my own tests, the only methods that will still need BTX/ETX after<br>
the merge are methods that take pointers to special type, because the<br>
wrappers will think these are vtkObjectBase-types.  I have a list of<br>
these methods that I can send along after the merge.  It&#39;s easy to<br>
find these methods, because the Java wrappers fail to build when it<br>
encounters them.<br>
<br>
To solve this issue in the long term, I&#39;m working on a tool that can<br>
make a text file that describes the VTK class hierarchy (both for<br>
vtkObjects and for special VTK types).  Through the use of this file,<br>
when the wrappers encounter a parameter called &quot;vtkSomething&quot; they<br>
will know at compile-time whether vtkSomething is a vtkObject.<br>
<br>
   David<br>
<br>
<br>
On Fri, May 28, 2010 at 10:09 AM, Marcus D. Hanwell<br>
<div><div></div><div class="h5">&lt;<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>&gt; wrote:<br>
&gt; Hi David,<br>
&gt; Thanks for all of the work you have put into this. David Cole is going to<br>
&gt; look over the topic branch, hopefully at some point today. If he doesn&#39;t<br>
&gt; spot any major issues I would like to merge this into master early next<br>
&gt; week.<br>
&gt; I am certainly excited about the improvements you are bringing to the<br>
&gt; wrapping in VTK.<br>
&gt; Thanks,<br>
&gt; Marcus<br>
&gt; On Thu, May 27, 2010 at 4:52 PM, David Gobbi &lt;<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve pushed the last of the changes to my &quot;wrapping&quot; branch on github.<br>
&gt;&gt;  It&#39;s ready for merge.<br>
&gt;&gt;<br>
&gt;&gt;   David<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, May 26, 2010 at 4:49 PM, David Gobbi &lt;<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; In the new wrappers, there is already full support vtkStdString<br>
&gt;&gt; &gt; support Tcl and Java, and I&#39;ve even added string regression test for<br>
&gt;&gt; &gt; Tcl.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Unicode was easy to add to Python (a few hours work), and it should be<br>
&gt;&gt; &gt; similarly easy for someone to add it for Tcl and Java.  There are<br>
&gt;&gt; &gt; plenty of people who want it, I&#39;m sure.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Divergence is a concern, but at least all wrappers use the same<br>
&gt;&gt; &gt; front-end, so transferring enhancements from one set of wrappers to<br>
&gt;&gt; &gt; another is that much easier.  And Brad King mentioned a wrapper<br>
&gt;&gt; &gt; utility .cxx that all wrappers use... this would be great, because<br>
&gt;&gt; &gt; right now there is a huge amount of code duplication.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I&#39;ll switch over to the branch immediately, and in the future I will<br>
&gt;&gt; &gt; make branches for any other projects that involve multiple classes.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;   David<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Wed, May 26, 2010 at 3:58 PM, Marcus D. Hanwell<br>
&gt;&gt; &gt; &lt;<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; Hi David,<br>
&gt;&gt; &gt;&gt; On Wed, May 26, 2010 at 5:46 PM, David Gobbi &lt;<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>&gt;<br>
&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Thanks for doing this!  I was not looking forward to doing the<br>
&gt;&gt; &gt;&gt;&gt; clean-up work myself... when I started it never occurred to me to<br>
&gt;&gt; &gt;&gt;&gt; create a branch, my plan was to eventually re-base my changes on the<br>
&gt;&gt; &gt;&gt;&gt; VTK master.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Topic branches are much easier for us to work with, and if you avoid<br>
&gt;&gt; &gt;&gt; merging<br>
&gt;&gt; &gt;&gt; into them/rebasing then the eventual merge into master becomes simpler.<br>
&gt;&gt; &gt;&gt; Now<br>
&gt;&gt; &gt;&gt; that we have it you could continue your work in that branch, or we<br>
&gt;&gt; &gt;&gt; could<br>
&gt;&gt; &gt;&gt; cherry pick the commits you make.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; There are just two minor changes that I can squeeze in over the next<br>
&gt;&gt; &gt;&gt;&gt; two days, and I will email you when they are done.  After that, the<br>
&gt;&gt; &gt;&gt;&gt; sooner that the branch can be merged into master, the better.  In<br>
&gt;&gt; &gt;&gt;&gt; order for the special-type wrapping to be fully realized, most (or<br>
&gt;&gt; &gt;&gt;&gt; all) of the BTX&#39;s will have to be removed from the code.  A change<br>
&gt;&gt; &gt;&gt;&gt; that big will probably be easier to do in the master than to merge in<br>
&gt;&gt; &gt;&gt;&gt; from a branch.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; A global change like that is definitely something that would be easier<br>
&gt;&gt; &gt;&gt; done<br>
&gt;&gt; &gt;&gt; in master as you say. We can take care of that once it looks ready to<br>
&gt;&gt; &gt;&gt; go<br>
&gt;&gt; &gt;&gt; in.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I&#39;ve already tested VTK (with python, tcl, and java) without BTX/ETX.<br>
&gt;&gt; &gt;&gt;&gt; The Tcl and Java wrappers compiled and tested cleanly, and so did<br>
&gt;&gt; &gt;&gt;&gt; Python after I did some small fixes to the way that it does special<br>
&gt;&gt; &gt;&gt;&gt; type wrapping.  It is these python fixes that I need to commit before<br>
&gt;&gt; &gt;&gt;&gt; the merge.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; I think one of the remaining concerns is how much the wrapping might<br>
&gt;&gt; &gt;&gt; diverge, i.e. if Python supports vtkVariant, unicode, vtkStdString etc<br>
&gt;&gt; &gt;&gt; but<br>
&gt;&gt; &gt;&gt; other languages did not. I am certainly very pleased with the changes<br>
&gt;&gt; &gt;&gt; in<br>
&gt;&gt; &gt;&gt; Python, and can see how much it will improve the Python wrapping in<br>
&gt;&gt; &gt;&gt; charts<br>
&gt;&gt; &gt;&gt; and infovis.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; There are other changes that I&#39;m planning for the Python wrappers<br>
&gt;&gt; &gt;&gt;&gt; (enums, etc) but for them I&#39;d prefer to wait until after the merge.<br>
&gt;&gt; &gt;&gt;&gt; I&#39;ll put together a wiki page so that they can be reviewed.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; You could publish them in a topic branch for us to review. The main<br>
&gt;&gt; &gt;&gt; caveats<br>
&gt;&gt; &gt;&gt; remain to avoid rebasing/merging from master. Once we are ready to<br>
&gt;&gt; &gt;&gt; merge<br>
&gt;&gt; &gt;&gt; into master we can take care of that. Thanks for putting this together,<br>
&gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; to Keith for preparing this topic branch.<br>
&gt;&gt; &gt;&gt; I am very hopeful that we can merge these changes in soon. We have been<br>
&gt;&gt; &gt;&gt; working away behind the scenes to get this ready to be reviewed and<br>
&gt;&gt; &gt;&gt; merged<br>
&gt;&gt; &gt;&gt; in.<br>
&gt;&gt; &gt;&gt; Thanks,<br>
&gt;&gt; &gt;&gt; Marcus<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; On Wed, May 26, 2010 at 2:39 PM, Keith Fieldhouse<br>
&gt;&gt; &gt;&gt;&gt; &lt;<a href="mailto:keith.fieldhouse@kitware.com">keith.fieldhouse@kitware.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;&gt; &gt; David<br>
&gt;&gt; &gt;&gt;&gt; &gt; I&#39;ve been spending some time looking at your Wrapping work.  It<br>
&gt;&gt; &gt;&gt;&gt; &gt; appears<br>
&gt;&gt; &gt;&gt;&gt; &gt; that<br>
&gt;&gt; &gt;&gt;&gt; &gt; your git tree was built with a mixture of rebasing and merging which<br>
&gt;&gt; &gt;&gt;&gt; &gt; resulted in a somewhat wonky commit history (duplicated commits<br>
&gt;&gt; &gt;&gt;&gt; &gt; interspersed<br>
&gt;&gt; &gt;&gt;&gt; &gt; with commits coming from VTK master).<br>
&gt;&gt; &gt;&gt;&gt; &gt; In order to get a clean topic branch that will be a little easier<br>
&gt;&gt; &gt;&gt;&gt; &gt; for<br>
&gt;&gt; &gt;&gt;&gt; &gt; folks<br>
&gt;&gt; &gt;&gt;&gt; &gt; here to look at (and to eventually merge with master) I spent a  bit<br>
&gt;&gt; &gt;&gt;&gt; &gt; of<br>
&gt;&gt; &gt;&gt;&gt; &gt; time<br>
&gt;&gt; &gt;&gt;&gt; &gt; untangling your history (mostly by examining parentage and looking<br>
&gt;&gt; &gt;&gt;&gt; &gt; at<br>
&gt;&gt; &gt;&gt;&gt; &gt; commit<br>
&gt;&gt; &gt;&gt;&gt; &gt; subjects).  In the end, by cherry picking the right commits in what<br>
&gt;&gt; &gt;&gt;&gt; &gt; I<br>
&gt;&gt; &gt;&gt;&gt; &gt; considered the &quot;right&quot; order I was able to build a clean topic<br>
&gt;&gt; &gt;&gt;&gt; &gt; branch<br>
&gt;&gt; &gt;&gt;&gt; &gt; with<br>
&gt;&gt; &gt;&gt;&gt; &gt; no conflicts.  Once I had that, I rebased it against master (as of<br>
&gt;&gt; &gt;&gt;&gt; &gt; this<br>
&gt;&gt; &gt;&gt;&gt; &gt; afternoon sometime when I did it).  The result can be found in<br>
&gt;&gt; &gt;&gt;&gt; &gt; git://<a href="http://github.com/keith-fieldhouse/VTK.git" target="_blank">github.com/keith-fieldhouse/VTK.git</a><br>
&gt;&gt; &gt;&gt;&gt; &gt; As the topic branch Gobbi/Wrapping.<br>
&gt;&gt; &gt;&gt;&gt; &gt; The result builds and the tests run so I believe that I&#39;ve built a a<br>
&gt;&gt; &gt;&gt;&gt; &gt; representative branch from your work.<br>
&gt;&gt; &gt;&gt;&gt; &gt; If you plan on doing additional work on this, would it be possible<br>
&gt;&gt; &gt;&gt;&gt; &gt; for<br>
&gt;&gt; &gt;&gt;&gt; &gt; you<br>
&gt;&gt; &gt;&gt;&gt; &gt; to grab this topic branch and work on that (without rebasing or<br>
&gt;&gt; &gt;&gt;&gt; &gt; merging<br>
&gt;&gt; &gt;&gt;&gt; &gt; for<br>
&gt;&gt; &gt;&gt;&gt; &gt; now)?    That way we&#39;ll have a clean topic branch  for an eventual<br>
&gt;&gt; &gt;&gt;&gt; &gt; merge<br>
&gt;&gt; &gt;&gt;&gt; &gt; to<br>
&gt;&gt; &gt;&gt;&gt; &gt; &quot;Next&quot; when we switch to branchy development for VTK.  Or if branchy<br>
&gt;&gt; &gt;&gt;&gt; &gt; development comes later, this clean topic branch will be easier to<br>
&gt;&gt; &gt;&gt;&gt; &gt; rebase as<br>
&gt;&gt; &gt;&gt;&gt; &gt; well.<br>
&gt;&gt; &gt;&gt;&gt; &gt; Thanks again for your work on this.<br>
&gt;&gt; &gt;&gt;&gt; &gt; Keith<br>
&gt;&gt; &gt;&gt;&gt; &gt; --<br>
&gt;&gt; &gt;&gt;&gt; &gt; Keith Fieldhouse<br>
&gt;&gt; &gt;&gt;&gt; &gt; R&amp;D Engineer, Kitware Inc.<br>
&gt;&gt; &gt;&gt;&gt; &gt; (518) 836-2190<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>