Re: [PySide] Proposal for "Visual tool to fast edit type system files" -- a Pyside idea
higery
> of parsing C++ headers, type system xml description of the binding,
> and merge these two sets of information in something the binding
> generator may work with.
> At the moment it works only with both sets of information (headers +
> xml), but the ideal would be to modify it to take a given set of
> headears and from them produce an initial xml description (or the
> information needed by another tool to produce such xml file).
> This way you can't avoid dealing with C++. If you decide to do part of
> the work modifying APIExtractor, and part creating the tool that uses
> its information, you're still going to be in the C++ only camp.
> One interesting alternative is to, after improving APIExtractor lib to
> work as you need, produce Python bindings for it (or at least the
> parts useful for your goals) and use them to write your tool in
> Python.
Agree. So a plan in a sentence should be improving APIExtractor lib
first which can help generate the Python bindings as what I want , and
write such command tool using these bindings second.
Thank you very much!
> Such APIExtractor bindings would certainly be very useful in other
> contexts, and a good thing in itself.
I also hope so.
Best regards,
_______________________________________________
PySide mailing list
PyS...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
higery
> possible mark some methods that may need code injection or argument
> modification,
OK.
>I don't know if there are python C++ parsers are up to this task.
I also don't know; I think I should spend some time on investigating that first.
>> > In the perfect word source code, documentation and test are delivered
>> > weekly. =)
>>
>> OK. It maybe added in my weekly plan.
>
> I would mentor this proposal.
>
Thanks for your attention, I will (in 8 hours) paste an enhanced
proposal basing on discussings on this thread.
Best regards to all of you,
anatoly techtonik
>> Remember that the tool must parse the C++ headers to find classes and if
>> possible mark some methods that may need code injection or argument
>> modification,
> OK.
>
>>I don't know if there are python C++ parsers are up to this task.
> I also don't know; I think I should spend some time on investigating that first.
There is an article about parsing C++ with clang:
http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/
And frankly, I expected Shiboken to provide binding for C code as well, so
this can be covered to some degree in proposal too.
And I agree that having basis functionality first is more important
than GUI tools.
--
anatoly t.
higery
Sorry for replying a little late, I have created a newer proposal basing on all you guys' good idea and suggestions, however there still
are many details to talk over, any other suggestions about the project or my proposal are very appreciated.
Thank you to everyone!
-------------------------------------------------------------------------------------------------
Proposal -- "Useful tool to help bootstrap of new bindings"
Abstract
-----------------
Shiboken is a front-end plugin for Generator Runner which can generate bindings for C++ libraries using CPython source code. But because of complicated language syntax and runtime mechanism of C++, it seems a little difficult for people who use Shiboken very often to create Python bindings, and there are already some complains in the Pyside mailing list [?]. So, it’s very valuable and significant to implement a tool to help bootstrap of new bindings.
Introduction
------------------
This tool would be a command line tool, and when using it, people could inform the header files of libraries which they want to bind, after running, it will generate basic typesystem files for these libraries plus the CMakeFiles for the project.
To let APIExtractor do what we want, we have to modify APIExtractor, because it does the hard work of parsing C++ headers, typesystem XML description files of the binding, and must use these two sets of information that the binding generator may work with. So, an ideal way would be to modify APIExtractor to take a given set of headers and from them produce an intermediate XML description file, which contains the information needed by our tool to generate final binding typesystem files.
However, in the process of modifying work, we can’t avoid dealing with C++, thus it may be not practical for us to do part work of modifying APIExtractor while creating the tool that uses its information at the sametime. So, in this summer project, preliminary work will be modifying APIExtractor first, and writing the command tool second.
The following is the concrete weekly plan:
Timeline
------------------
Week 1: Get the clone of Pyside and Study the whole framework of APIExtractor through reading the source code.
Week 2-Week 8: Modify APIExtractor to do what we want. The detail is:
--Week 2: find the classes through parsing C++ headers
--Week 3: handle namespace-type, interface-type, object-type
--Week 4: extract primitive-type, enum-type,value-type
--Week 5: extract other complex typs like Template
--Week 6: handle C/C++ function and mark them if they need code injection or argument modification or not
--Week 7: can extract all exportable symbols from the given library
--Week 8: write these information to an intermediate XML file
Week 9-Week 12: Create the command tool to help bootstrap of new bindings and do test work
--Week 9: write Python script to offer function of generating new binding typesystem files from the intermediate file created before
--Week 10: write tests against such script
--Week 11: through times testing, check if the previous modifying work on APIExtractor behaves well or not
--Week 12: help improve our command tool in return
Week 13-Week14: perfect the code and documentations, and begin to submit patches
--Week 13: perfect the code and documentations
--Week 14: create patches and try to submit them
Week 15….: summarize the whole work and say goodbye to summer
About me
--------------------
I'm an undergraduate from China and I'm preparing for my computer science and technology bachelor degree in USTB (University of Science and Technology Beijing). Java and Python is the main programming language when I write programs and software.
During my coding days, I’m getting to know more and more about the Open-Source/FOSS, especially its spirits-share, collaborate, make friends. Every time I find an excellent solution about some problems occurred to me, I become so excited and learned a lot from the process of problems finding-reporting-solving.
I joined gsoc2011 last year and took one Python idea as my summer project, you can take a look at what the project does via python wiki page http://wiki.python.org/moin/SummerOfCode/2011/SetuptoolsFeatures, and you also can know more through my blog for gsoc: http://higery.wordpress.com/
Contact Info:
# Name: Xu Dehai(You can call me with my English name-higery)
# Blog: http://higery.wordpress.com/
# IRC: higery on irc.freenode.net
higery
> possible it will ease a lot your work and you can forgot about the
> ApiExtractor modification.
OK.
> I think you need to send this proposal via google-melange, then you can
> improve it there.
Sure, I will submit my proposal ASAP. I paste my proposal here rather
than google-melange, because I'm afraid that mentors may still not see
students' proposals before the application deadline while maybe I'm
wrong.
Stefan Champailler
But, for having had to have a look inside Shiboken and all that stuff,
I'd say what's missing most is documentation. There's a lot of it, but a
walkthrough, from beginning to end would be very nice. For example, the
ownership stuff is not crystal clear, there are a lot of corner cases
which, I felt, are not documented enough for people like me who :
- are pretty fluent in programming Python and C++
- but are not familiar with the way the bindings work between Python and C++
I know documentation is not the funniest part but that would really help
people like me, outside the PySide core team, to be able to be
autonomous without having to work/read for days before understanding a
bit of what is happening...
I hope I don't sound too harsh, that's not my point, I use PySide a lot
now and as a product it is really good and reliable. It's just that when
I meet a bug it's very hard to dive into the Shiboken code and get a
grasp of what's happening. Especially when one knows that it is not that
complicated...
So the tool would be nice, but it has to make the inner workings of the
binding tools very clear. So I see that tool has something to help me to
more easily understand and fix PySide.
(and again I love PySide :) I'm very grateful of having such a tool for
free)
Stefan
On 03/27/2012 05:24 PM, higery wrote:
> The following is my GSOC2012 proposal although in a very preliminary way, I
> will
> appreciate anyone can make some suggestions about this proposal.
higery
This in an interesting proposal.
But, for having had to have a look inside Shiboken and all that stuff,
I'd say what's missing most is documentation. There's a lot of it, but a
walkthrough, from beginning to end would be very nice. For example, the
ownership stuff is not crystal clear, there are a lot of corner cases
which, I felt, are not documented enough for people like me who :
- are pretty fluent in programming Python and C++
- but are not familiar with the way the bindings work between Python and C++
I know documentation is not the funniest part but that would really help
people like me, outside the PySide core team, to be able to be
autonomous without having to work/read for days before understanding a
bit of what is happening...
I hope I don't sound too harsh, that's not my point, I use PySide a lot
now and as a product it is really good and reliable. It's just that when
I meet a bug it's very hard to dive into the Shiboken code and get a
grasp of what's happening. Especially when one knows that it is not that
complicated...
So the tool would be nice, but it has to make the inner workings of the
binding tools very clear. So I see that tool has something to help me to
more easily understand and fix PySide.
(and again I love PySide :) I'm very grateful of having such a tool for
free)
Stefan
Thank you for your attention, I will try my best to implement such a tool.