Thanks David! <div><br></div><div>I was able to narrow down the problem yesterday night. What I believe that was causing the strange error on my mac was that llvm+clang 2.9 did not have some methods listed on the bindings from clang. The problem was that mac-os was complaining about something else instead of telling me that. I run that on a Ubuntu and Debian os on my virtual machine and after moving from 2.9 to 3.0 and finally to 3.1 I finally was able to observe the Debian os complaining about the lack of the function being imported on llvm+clang 2.9 and notice by 3.1 the problem was solved. Curiously enough the llvm 3.1 on Debian did not work either, but when I moved back to llvm 3.1 on asserts+debugs on my mac it finally run the code without any modification.</div>
<div><br></div><div>I am actually grateful for finding the interface on Python since even some things I couldn't make sense on the Doxygen on how to use (there are not many working examples floating around of lib clang nor the python interface), I found how their meaning from the comments written on the Python interface. </div>
<div><br></div><div>I am still wondering thou on how to print a tree on the C version as to identify something that mimics the get_children from python or at the very least let me know when it hits a leaf, but the Python solution work just as fine. </div>
<div><br></div><div>Please let me know if you want any more details in respect to this matter, I would be glad to provide of any of the os or the llvm+clang versions.</div><div><br></div><div>Best Regards,</div><div><br>
</div>
<div><div>Carlos Andrade<br><div><a href="http://carlosandrade.co" target="_blank">http://carlosandrade.co</a></div><br>
<br><br><div class="gmail_quote">2012/6/18 David Röthlisberger <span dir="ltr"><<a href="mailto:david@rothlis.net" target="_blank">david@rothlis.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 17 Jun 2012, at 17:45, Carlos Andrade wrote:<br>
><br>
> Hi David, thanks for replying.<br>
><br>
> Yes I did narrow down the problem to a more specific line, if I run this code which was provided at [2] and I adapted a small piece of [1]:<br>
><br>
> -----<br>
> import sys<br>
> import clang.cindex<br>
><br>
> def callexpr_visitor(node, parent, userdata):<br>
> if node.kind == clang.cindex.CursorKind.CALL_EXPR:<br>
> print 'Found %s [line=%s, col=%s]' % (<br>
> clang.cindex.Cursor_displayname(node), node.location.line, node.location.column)<br>
> return 2 # means continue visiting recursively<br>
><br>
> index = clang.cindex.Index.create()<br>
> tu = index.parse(sys.argv[1])<br>
> #clang.cindex.Cursor_visit(<br>
> # tu.cursor,<br>
> # clang.cindex.Cursor_visit_callback(callexpr_visitor),<br>
> # None)<br>
> print 'Translation unit:', tu.spelling<br>
> f = tu.get_includes()<br>
> print 'test'<br>
> ------------------<br>
> Adding the method in red makes it crash, That is, the tu.get_includes crashes. I look at the cindex.py but I cant figured what is wrong it seemed to me like a normal use of the method.<br>
<br>
</div>Sounds like a bug to me -- you could raise it in the clang bugtracker.<br>
Though first you should check that it hasn't been fixed already; you'd<br>
have to build from the latest sources and test against that.<br>
<br>
If you do raise a bug, make sure you minimise the failing code to the<br>
smallest possible test case (there's no need for the callexpr_visitor,<br>
or the commented-out code). You will also need to include the C++ code<br>
that you parse with your tool, because the bug may only happen with<br>
certain inputs. Again, reduce this code sample to the absolute minimum<br>
that will still trigger the bug.<br>
<div class="im"><br>
<br>
> The reasons I stayed on C was because I saw few comments that python was still catching up on making available the methods provided by libclang,<br>
<br>
</div>That's true in the sense that any new feature must be added to the C<br>
interface before it can be added to the python bindings; that is just<br>
the nature of foreign bindings. But I don't know how far behind the<br>
python bindings are currently lagging (if at all). Gregory Szorc (CCd)<br>
is one of the maintainers of the python bindings -- perhaps he can<br>
comment.<br>
<br>
Good luck :-)<br>
Dave.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> 2012/6/17 David Röthlisberger <<a href="mailto:david@rothlis.net">david@rothlis.net</a>><br>
> On 17 Jun 2012, at 08:24, Carlos Andrade wrote:<br>
>><br>
>> I managed to create a transversal using libclang on C, map it to code and get its types but now I am stuck trying to output it like a tree like it is done at [1]. For some unknown reason [1] crashes here with the warning "Python quit unexpectedly while using libclang.dylib plug-in. (Running on an OS Lion).<br>
>><br>
>> [1] <a href="https://gist.github.com/2503232" target="_blank">https://gist.github.com/2503232</a><br>
><br>
> Can you narrow down the failure to a specific line of python + line of<br>
> the input translation unit? I suspect it might be something to do with<br>
> accessing a property of an invalid type.<br>
><br>
>> On my C version I can get each node being printed, but what I wanted is what [1] does: Print the structure of the tree (who is child of who) and I was trying to do so by tying to verify if the child is NULL but I cant find any method available to do so. [2] Seems to suggest this doesnt even exist on libclang C.<br>
>><br>
>> [2] <a href="http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/" target="_blank">http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/</a><br>
><br>
> Have you considered writing your program in python? I found that using<br>
> the ipython shell (with its tab-completion) was really helpful for<br>
> exploring the libclang API.<br>
><br>
> (I apologise for not actually answering your question, but I don't know<br>
> enough about the libclang C interface.)<br>
><br>
> Cheers<br>
> Dave.<br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>