<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">New patch fixes formatting per Manuel's
feedback in another email.<br>
<br>
On 6/25/12 12:47 AM, Manuel Klimek wrote:<br>
</div>
<blockquote
cite="mid:CAOsfVvkPWaDH6EB8Cc2eSjBNmy-ni5dvme3smwh-Eoge9LDYOw@mail.gmail.com"
type="cite">
<div style="font-family: arial, helvetica, sans-serif"><font
size="2">
<div>+ #lib.clang_annotateTokens.argtype =
[TranslationUnit, POINTER(Token),</div>
<div>+ # c_uint,
POINTER(Cursor)]</div>
<div><br>
</div>
<div>Is this intentionally commented out?</div>
<div><br>
</div>
<div>In general, I like the patch - it's pretty straight
forward, so the biggest concerns would be high level.</div>
<div>Perhaps you can loop in whoever originally designed the
API for an opinion :)</div>
<div><br>
</div>
<div>Cheers,</div>
<div>/Manuel</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div class="gmail_quote">On Sat, Jun 23, 2012 at 7:23 AM,
Gregory Szorc <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gregory.szorc@gmail.com" target="_blank">gregory.szorc@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've
been wanting to do this for a while: this patch refactors
how the<br>
libclang functions are registered in the Python bindings.<br>
<br>
Instead of creating a separate symbol for each libclang
function, we<br>
perform the ctypes magic directly on an instance of the
libclang<br>
library. Things are defined in a function in the rare case
someone<br>
wants to have multiple handles to the libclang library.<br>
<br>
This increases the cohesion between libclang and the
Python bindings<br>
and IMO makes the Python easier to read since you don't
need to<br>
maintain a mapping from the Python function name to the
libclang<br>
function name.<br>
<br>
Since this deletes symbols from the module, this is
technically<br>
backwards incompatible. But, I would argue that people
should never<br>
have been using these symbols directly (they offer little
benefit<br>
without the classes in the module).<br>
<br>
This will bit rot the compilation database patch that is
pending<br>
review on this list. I don't like bit rotting people, so I
may hold<br>
off landing this until after that patch.<br>
<br>
There is a high risk of typos in this patch. The nose
tests all pass,<br>
but our test coverage isn't perfect.<br>
<br>
Some function definitions from missing features (tokens,
resource<br>
usage) are commented out because I cherry-picked this
patch from my<br>
personal branch and these features were implemented in
that branch<br>
before this patch. I'll simply remove the comments once
those<br>
corresponding features land (which will be shortly, I
hope).<br>
<span class="HOEnZb"><font color="#888888"><br>
Gregory<br>
</font></span><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br>
</blockquote>
</div>
<br>
</font></div>
</blockquote>
<br>
</body>
</html>