Happy Holi everyone (holi is an Indian festival of colors)
Thank you Nicolas for your valuable response
I understood all your points and will surely make changes in the proposal.
The tools here I referred are both pygccxml and libclang.
There is trade off for both the tools:-
1). Pygccxml takes up a quite a bit of computation time while libclang is better in this case.
2). Pygccxml is quite mature and also has a proper documentation which gives it advantage over libclang.
3). Pygccxml generates a nice AST which is really understandable and easy to work with while this is not the case in libclang.
4). Still libclang is really popular C++ parsing tool and is under continuous development which gives us an excellent opportunity to explore it.
So, I think it's worth it to use both of them to parse header files.
I definitely know that the most important part of the project is about extracting most of the information from the header files, but I thought that the ultimate goal is to create YAML files for the GRC. I will definitely make these changes and I'm really sorry for the confusion created due to this in the proposal.
So, Should I proceed using both the tools?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Read the mailing list of the GNU project right here! The information here is regarding the GNU radio project for USRP radios.
Thursday, March 21, 2019
Re: [Discuss-gnuradio] Propsal draft: Block Header Parsing Tool
Hey Arpit,
thanks for your answer. As if you should proceed using both the tools: if you think it's worth it, go for it. But be careful about the timeframe of the program. You might don't want to spend a significant portion of the already limited coding time into doing the parsing twice. Here I have to admit that I ignore how much effort would it represent to support the two libraries from the beginning.
If you choose to support both, I'd suggest a small change in the proposed timeline: choose one, stick to it and use it to generate both the AST and then the YAML files for GRC, integrate it into gr_modtool, and after it all is stable, extend the parsing options to take the other parser library, which would be nice to have.
I mention this because I'd rather the focus of the project to be concentrated in the block header tool than in providing two wrappers for a parsing library that fulfill effectively the same purpose. However, this is (as of now) only a suggestion. I'm open to hearing arguments otherwise.
Cheers,
-Nico
On Thu, Mar 21, 2019 at 11:07 AM Arpit Gupta <guptarpit1997@gmail.com> wrote:
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment