Three week ago I wrote two exams, which I had to learn. Therefore I had no time for Anjuta. My energy for this semester was as well as consumed and the documentation for Clang is not really the best. Finally the Olympic games were no help, because that were too exciting to ignore that games. So a TV in my room interrupted me frequently from programming. ;-)
Thus after finish merging same code of the language support plugins I hadn’t find many time to write the Clang plugin. As you can see my code this plugin isn’t complete, but it’s a good base to complete it.
Unfortunately I won’t have time for Anjuta in the near future, because I have to write some exams and add some new feature to my other project Sudowars, which is open source since a couple of weeks. But I’m going to complete the Clang plugin and fix some bugs in Anjuta.
My thanks goes to the Anjuta team and specially on my mentor Johannes. They helped me a lot and I learned many things during Google Summer of Code. I would do it again at any time.
The cache behaviour for each language plugin is still the same as before, because the procedure is partial very different. However where I could find similarities, I merged the code to the new parser-engine plugin.
From time to time it’s a little bit troublesome. For example yesterday the editor didn’t show the proposals for the word, which I started to type. I searched about six hours to find a solution for the problem. Finally I read the source code of given methods, which I used in my code and couldn’t find any documentation. I found out what each method does exactly and could solve the problem.
I hope that I finish my work on merging the language plugins very soon and devote my time to the real work: the clang plugin.
As part of merging code and unifying the behaviour of each language plugin I improved the Vala plugin. Calltips show method names and return types now instead of only the parameters of the function as it was before.
The Python preferences before and after
Additionally the vala plugin has its own preferences widget now. Before it used the preferences of the cpp-java plugin. As a consequence the Vala plugin no longer depends on the cpp-java plugin. While doing this work I learned, how I can integrate C interfaces in a plugin, which is written in Vala.
But the Vala plugin is not the only one which got an update. The Python plugin has the “Add ‘)’ after function call autocompletion” option now. With this new option the Python plugin has the same functionality as the other language plugins and so I made the preference widget looking like the preferences widget of the other plugins.
Moreover I added the new behaviour of C/C++ in Python and cleaned up the Python plugin a little bit for example of deleting unused variables.
Last week I learned how autogen works. Therefore I had the ability to adapt the new parser-clang plugin so that the plugin will be only build, if llvm and clang are available on the system. Otherwise it will be ignored by the compile process. After this work I played a little bit with clang. Once you know the way of working of clang it’s very easy to program with it.
This week I continued with splitting language plugins in a parser part. The language-support-python plugin does nothing other than operate with rope. And at first view this is also the same case at the language-support-js plugin. So splitting these two plugins makes no sense, because after that, there is no basic plugin left in the basket, which we can use as a language-support plugin. The Vala language-support plugin has some dependencies on the parser part, which are not trivial to solve.
Hence I stop splitting the language-support plugins and finally I split only the language-support-cpp-java plugin. The new interface for the completion engine is called IAnjutaParser. So I integrate IAnjutaParser in the Vala, Python and JS language-support plugin now. Only C/C++ has its own parser plugin and consequently not the language-support-cpp-java plugin, but the two parser plugins parser-cxx and parser-clang integrate the IAnjutaParser interface.
Last weekend I began to split the parser part from each language plugin to a separate plugin. In the future the parser is going to be used as an adapter by the language support interface. This makes the code more uniform and I hope we can merge some code.
All in all the language-support plugins shouldn’t manage any more the own parser part, because they can access a common parser base. Now the parser plugin itself decides which parser is used, which is then only loaded if the corresponding programming language is used.
In the last days I learned how interfaces works under Anjuta and C. Until then I only knew it from Java.
By the way you can take a look at my current code on github.
What I’ve done this week:
- Finish splitting the language-support-cpp-java plugin in an indentation-c-style plugin and a language-support-cpp-java plugin without the indentation part
- Did the same with language-support-python plugin
- Export the utils classes of the two language-support plugins to libanjuta/anjuta-utils to prevent code duplication
What I’ve done this week:
- Split the language-support-cpp-java plugin in an indentation-c-style plugin and a language-support-cpp-java plugin without the indentation part
- Read the documentation about the plugin system of anjuta
Splitting the plugin took more time and was more challenging than expected. The main problem was to understand what each method does. So I had to read much documentation. I’m not already done with this work, but I’m on a good way…
I’m accepted with my proposal on Google Summer of Code for this year. My mission is to bring clang magic to Anjuta. “Anjuta? What is Anjuta?”, maybe you wonder yourself now. Anjuta is a IDE just like Eclipse.
Clang is a compiler front-end for the LLVM compiler. With this compiler front-end for C, C++, Objective C and Objective C++ code we can get better results in Anjuta. For example if you make a simple mistake by writing code Anjuta will warn you. This can save a lot worse.
The first major obstacle is to make thoughts about the future architecture of the language support interface, so that you’ll be simple load plugins for a language feature like autocompletion or indentation. To support this purposes I’ll split up already available language plugins in an indentation part and the support part.
