I got a serious query regarding usage of *Clang* in C parser for further implementation cases such as implementing assignment and loops.
Actually, I was trying to implement conversion for "*if statement*" in C parser. So, after traversal, what I got from the AST was IF_STMT. And in its child node, BINARY_OPERATOR was obtained. Now naturally, I wanted to know the type of binary operator But, unfortunately, I found out that the *type* of binary operator(e.g. =, <=, +, -, /, *) cannot yet be obtained from clang python bindings (i.e *clang.cindex*), because the same is currently under development. Later, I found that the type of unary operators also cannot be obtained. For implementing loops too, we will need to parse assignment operator(a binary operator) as well as increment/decrement(unary operators). Same will be the case for implementing aug_assign(shorthand operators/ simple perform operation and assign in C) Conclusion is that either we have to wait until the release of Clang which will contain these improvements or find some alternatives. Please suggest what to do in this context as soon as possible! One option can be implementing it from scratch using *pycparser, *which is very well developed. Even if you agree with this, I will start making PRs(which use pycparser) soon and cope up with the current situation for C parser until GSoC (since I am available now because of current condition in the nation) Other option can be changing *clang.cindex* and some cpp files in clang, which is advised by some people of clang community, but that doesn't seem feasible from a user point of view. Also, I have updated my proposal according to the suggested changes. Please review it and suggest appropriate changes. I have to update it soon since deadline is near! (I will have to change Clang to Pycparser if in case. I have already started learning it.) On Wed 25 Mar, 2020, 3:56 AM Gajjar Smit, <[email protected]> wrote: > Agreed. First, finish off with most part of C parser(since it has more > priority), before digging into Java parser and then, whatever is left in C > can be done along with Java. > > On Tuesday, 24 March 2020 21:23:18 UTC+5:30, Aaron Meurer wrote: >> >> I think either way is fine. If you suspect things will come up in the >> C parser that you won't notice until you have done work in the Java >> parser, then it makes sense to split it. Otherwise, it is cleanest to >> do it all at once. >> >> Aaron Meurer >> >> On Mon, Mar 23, 2020 at 3:29 PM Gajjar Smit <[email protected]> wrote: >> > >> > Hi, I need a suggestion regarding the timeline. >> > >> > Should I distribute the remaining implementation of C >> parser(implementing loops and other functions) across all 3 phases or >> should I complete it in the first phase and then proceed to Java Parser? >> Suggest any other way if it is better! >> > >> > On Mon 23 Mar, 2020, 9:03 PM Gajjar Smit, <[email protected]> wrote: >> >> >> >> Thanks for the feedback, Nikhil! >> >> I did not know that I disabled comment access. I tried to resolve >> that. Please see if it is accessible now. >> >> >> >> Also, I can include, improving C parser if that can also be done in >> the timeline since I am now quite familiar with the C parser code. >> Currently, while statement, for statement, break token, continue token and >> if statement are not implemented in C parser code. Initially, I thought, it >> might not be completed in the summer. But, I can definitely include that >> now in the proposal along with Java parser. >> >> >> >> >> >> On Mon 23 Mar, 2020, 8:42 PM Nikhil Maan, <[email protected]> >> wrote: >> >>> >> >>> I looked through the proposal and have some suggestions. Can you >> provide comment access to the people with the link? I think it'd be better >> to comment directly on the proposal. >> >>> As for your queries: >> >>> 1) I will be mentoring for the project. >> >>> 2) No, you do not need to provide more details in the Milestone >> overviews, but you can use something like implement variable declarations >> instead of transform_variable_declaration() . I think a little more can be >> done each month than what is currently proposed. >> >>> >> >>> If you are familiar with C and C++ and its syntax, and seeing you >> have a few PRs improving the current parsers, you are familiar with the >> current parsers, >> >>> Can you also improve the current C parser during this GSoC period, >> like implementing loops and other stuff which are not currently implemented >> in the C parser, but you are proposing for the Java parser? >> >>> >> >>> Regards, >> >>> Nikhil Maan >> >>> >> >>> On Monday, March 23, 2020 at 4:07:32 AM UTC+5:30, Gajjar Smit wrote: >> >>>> >> >>>> Here is the docs link to my GSoC Proposal: >> https://docs.google.com/document/d/1HFWvBV-NjQVd2Tvv4-_tlNrGG52WWxJUlUlByLxfOog/edit?usp=sharing >> >>>> >> >>>> Please go through it. Any form of suggestions are most welcome! >> >>>> >> >>>> Few queries: >> >>>> >> >>>> Who will be the potential mentor if this project gets selected? >> >>>> Do let me know if "Overview of Milestones" part after each phase, >> showing high level implementation of code should have more details or is it >> sufficient! >> >>>> >> >>>> Thanks >> >>>> On Tuesday, 17 March 2020 01:00:44 UTC+5:30, Gajjar Smit wrote: >> >>>>> >> >>>>> I will surely look into the commonalities in those modules if they >> exist and will raise relevant issue! >> >>>>> >> >>>>> On Tue 17 Mar, 2020, 12:46 AM Aaron Meurer, <[email protected]> >> wrote: >> >>>>>> >> >>>>>> Another thing to consider, since this would be the third such >> language >> >>>>>> to be supported in SymPy (after C and Fortran), is if there are >> >>>>>> commonalities in the parsing code for each that should be factored >> out >> >>>>>> into a helper submodule. >> >>>>>> >> >>>>>> Aaron Meurer >> >>>>>> >> >>>>>> On Mon, Mar 16, 2020 at 1:12 PM Gajjar Smit <[email protected]> >> wrote: >> >>>>>> > >> >>>>>> > Thanks Aaron and Nikhil for suggestions. >> >>>>>> > >> >>>>>> > I have gone through javalang package and tried out few examples. >> AST nodes can be traversed in javalang and children can be accessed. Here, >> every relevant bunch of tokens are represented as an object of superclass >> CompilationUnit(somewhat similar to TranslationUnit in clang) which is >> again a subclass of generalized Node class. (Link to the javalang repo) >> >>>>>> > A basic example of tree traversal is attached as image. >> >>>>>> > >> >>>>>> > >> >>>>>> > I went through AST hierarchy in sympy ast module. I am also >> trying to understand generic sympy_expr module. >> >>>>>> > Should I start working on my proposal in this direction? >> >>>>>> > >> >>>>>> > -- >> >>>>>> > You received this message because you are subscribed to the >> Google Groups "sympy" group. >> >>>>>> > To unsubscribe from this group and stop receiving emails from >> it, send an email to [email protected]. >> >>>>>> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/f3d1221b-e731-49e0-9c01-09671f7fbb02%40googlegroups.com. >> >> >>>>>> >> >>>>>> -- >> >>>>>> You received this message because you are subscribed to the Google >> Groups "sympy" group. >> >>>>>> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> >>>>>> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2Bh2H33AehhfmsPgFBD0fkz7-X4cTEx4tOy3w4N2XUuPA%40mail.gmail.com. >> >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups "sympy" group. >> >>> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> >>> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/d3eefb38-7af2-45d1-ad3f-1c4d11be805f%40googlegroups.com. >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "sympy" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CA%2B%2BiR_zmbZGyCtQcsou5%2Bo713S6XEV%2Bn4Pjv9LXozt7pUhxcMw%40mail.gmail.com. >> >> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/b719a8e4-3004-449b-9d90-6adcea3703de%40googlegroups.com > <https://groups.google.com/d/msgid/sympy/b719a8e4-3004-449b-9d90-6adcea3703de%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CA%2B%2BiR_ymj%3DZLPPkjbNmRSAp6HZVpEsuLKiZgiX%3D5yvnni3d3DQ%40mail.gmail.com.
