• I successfully implemented a new action for DuplicateFileBear - DeleteFileAction. Two instances of DeleteFileAction are passed when Result is yielded, one for each duplicate file. On applying first action it will delete first file and on applying the second action it will delete the second file.

  Click below to see a little demo

• I finally put what I did in Phase 2 (Support for bears to provide multiple patches) to use. Initially I had thought of implementing a new bear which will provide multiple patches but couldn’t find a good idea for it. Then when I was playing around with some bears to look for some custom actions which will be helpful, I realised that FilenameBear might just be what I was looking for. So user can specify what type of naming convention (camelCase, snake_case, ..) should all the filenames follow, and if any file doesn’t follow this convention then coala will change it for you. But if user doesn’t specify what naming convention to follow and uses the bear then coala tries to guess the convention depending on the language, and if it cannot guess the snake_case is used. But now if coala cannot guess naming convention then multiple patches are provided - snake_case is the original patch, and camelCase, Space Case,.. are provided as alternate patches.

  Again click to see a demo of this

  So you might have noticed one thing in the demo that alternate patches are shown as Show AlternatePatch 1, it would be better if Show camelCase or Show Space Case was displayed. But adding this feature will require initialising with action with a custom description which I plan on doing after GSoC ends. Click here to see the PR implementing this, travis and appveyor are passing but coverage is still not 100%. That needs to be done.

• I also have to write a tutorial which describes how to write bears which can suggest multiple patches. Also I have to write my final GSoC report. I will try to finish all the work today itself (hopefully).

So this most probably my last blog on GSoC and I have grown to like writing them. These three months having been a very good experience and I would like to thank coala for giving me this opportunity. I learned many things across this three months and also I have really liked contributing to open source. I hope I pass the final evaluations as well and get all of my code merged. Also thanks to my mentor Abhinav Kaushlya who has been super active and replies almost immediately. Goodbye!!

Anyways, I had completed most of my work in the first two phases, or so I thought. But I ran into a problem while work on a custom action for DuplicateFileBear. The action is DeleteFileAction, on applying it deletes a file. But that is not the problem, the problem arised when two instances of DeleteFileAction were passed by the bear. It was giving unexpected results, and the problem turned out that coala forms and action_dict, a dictionary with key as the name of the class of action object and value as the action object. Naturally key should be unique, and so the problem arised. I did face an similar problem in Phase 2, when more that one instances of AlternatePatchAction was added to the list of actions. That time I had added a custom get_metadata function to AlternatePatchAction class, but now this was not feasible. I needed a generic solution, first thought that came to my mind was to use a key which was unique to an object. After discussing with @abhishalya and @Makman2, I decided to change the key of action_dict to id of action object.

I spent most of my time doing this and fixing tests that were broken because of this. One of the change that was made was to remove staticmethod from get_metadata function. This led to some other changes in Processing module and one the tests in Processing module was breaking. I faced this issue in Phase 1 as well, but I could figure out the cause for this, so @abhishalya suggested a workaround for this. It worked that time, but now those changes had to be made, and I still couldn’t figure out why the test was failing.

To provide some context the test which was failing was this.

    def test_without_default_action_and_unapplicable(self):
        # Use a result where no default action is supplied for and another one
        # where the action is not applicable.
        old_is_applicable = ApplyPatchAction.is_applicable
        ApplyPatchAction.is_applicable = staticmethod(
            lambda *args: 'The ApplyPatchAction cannot be applied'
        )

        self.section.append(Setting(
            'default_actions',
            'NoBear: ApplyPatchAction, YBear: ApplyPatchAction'))
        with LogCapture() as capture:
            ret = autoapply_actions(self.results,
                                    {},
                                    {},
                                    self.section,
                                    self.log_printer)
        self.assertEqual(ret, self.results)
        capture.check(
            ('root', 'WARNING', 'YBear: The ApplyPatchAction cannot be applied')
        )

        ApplyPatchAction.is_applicable = old_is_applicable

        self.section.append(Setting(
            'no_autoapply_warn', True))
        with LogCapture() as capture:
            autoapply_actions(self.results,
                              {},
                              {},
                              self.section,
                              self.log_printer)
        capture.check()

(Wow, the colour scheme sucks) And the solution was adding one word:

ApplyPatchAction.is_applicable = staticmethod(old_is_applicable)

You wouldn’t believe how many hours I wasted debugging this, and the cause turned out to be so silly. I knew that is_applicable was a staticmethod but never realised that reference to it, old_is_applicable was not.

Now there is only one and half week till Phase 3 evalutions start and I plan to finish all my work is this week itself. This will give me some time to get reviews on my PR and hopefully get them merged.

The plan was to add a new attribute to the Result class called alternate_diffs. Bears can pass a list of alternate patches and they are stored in alternate_diffs. Later in ConsoleInteraction for each alternate_diff in alternate_diffs a instance of AlternatePatchAction was added. The idea is very similiar to adding mulitple instances of ShowPatchAction but since there is no diffs associated with an instance of ShowPathAction, AlternatePatchAction acts kind of like a wrapper and helps manipulate between the original patch and alternate patches. When an AlternatePatchAction is applied it swaps the value of result.diffs and self.diffs and calls ShowPatchAction with updated result.

This all sounded good but there were couple of small hiccups, coala creates a dictionary of all the actions with key as the name of the class. So with mutiple instances of AlternatePatchAction this was a bit of a problem as keys have to unique. When user is asked for an action to use, what gets printed on the screen as action description is whatever is the docstring of apply function of that action class. It don’t understand the choice of this but since docstring is same for all the instances, this was another problem. Finding a solution for this was not very difficult and you can check out the whole PR here.

Progress till now

In Phase 1, I sucessfully completed providing support for bears to define their actions and also implemented two actions for GitCommitBear: AddNewlineAction and EditCommitMessageAction. Here’s a little demo of them in action (pun not intended).

Beware, clicking on this will redirect you. I couldn’t figure out how to play it here itself. If you know how to do it, tell me.

While working on this I came across an interesting bug in color_letter function in ConsoleInteraction module. This function basically beautifies action names when they get printed on screen. The interesting thing about this was its implementation choice and the fact that no one caught this bug before. Explaining this bug will take a lot of time, if interested have a look here.

After this I also wrote a tutorial which will help write bear specific actions.

What’s next?

I have been working on next part of the project which is providing support for bears to suggest multiple patches. For this I have added a new attribute to Result class, alternated_diffs. It is a list of dictionary, where each element is a alternate patch. And for each of these alternate patch an instance of AlternatePatchAction is added. This solution is a little hackish but it works, and I don’t think there is any other way to do this without making huge changes to the core which is not worth it. I still have to test this and make some minor changes, and I also need content to write for the second blog so see you there.

What’s the new plan?

Till now I was planning on having all the actions - default actions and actions defined by bears in result.actions. This required me to change all the existing actions which had problems of it own. The new plan was to only store actions defined by bears in result.actions. Changes to existing action classes were no longer necessary and changes in ConsoleInteraction and Processing modules were very few.

TODO before Phase 1 ends

There only thing remaining is writing tests. TBH I don’t quite enjoy writing tests but they are very important part also because people can come up with any actions and new system should ideally work for everything. I have written some tests testing auto-application of bear actions. I also have to write some tests for the new action which I had implemented for GitCommitBear. Currently when there is no newline between shortlog and body of commit message, running coala will only give a message saying so. But with new action, AddNewlineAction coala will provide you with a option to add a newline. This project is all about providing support so actions like these which are only specific to certain bears work. This open up doors for contributors to get more creative with bear writing.

Plan for Phase 2

I have no plan.

That’s not entirely true. I have to write a tutorial on how to write new actions and maybe update some documentation. Also add support for multiple patches. Rain stopped long time ago and match is getting interesting so I will continue in the next one.

What was my plan?

So my idea was add a new attribute actions to Result class. This is a list of all the action instances. To allow this I had to revamp all the other existing actions. Currently, Result object is passed as an arugment to methods of action classes. But now actions instances were inside Result object and I had to pass that Result object to the action. Confusing right? I spent several minutes thinking about this and came up with a genius plan to pass necessary arguements to action objects when they are instantiated in a Result. I had started implementing this at the end of bonding period, made changes to Result and all the existing actions classes. Also wrote a new action(AddNewLineAction) for GitCommitBear, it adds a new line between shortlog and body of the commit message if it is not there. Also made all the changes ConsoleInteraction and Processing modules to incorporate the changes to result and action class. If you want to see them click here. Remember in the last blog I had written that I had this part figured I out, well guess what, I was wrong.

So what went wrong?

Till now I hadn’t noticed that when ShowPatchAction is applied, a result object is passed a parameter to a function call. But ShowPatchAction is a element of result.actions. And it’s just not worth to change the function.

What’s the plan now?

After I realised this I again spent several more minutes thinking and came up with another genius plan but I have been told to write two blog for each phase and I think this blog is long enough.

Ideally I would have liked to have @Makman2 as my mentor but so would have all the other students. But sadly he does not have any time to mentor a project. My project has three mentors @Vamshi99, @kriti21 and @abhishalya. Vamshi and kriti are previous year GSoC students, and abhishalya is a GCI student.

What do I have to do?

So basically my project is about changing how actions work in coala. What are actions you ask? Action basically means the action to be taken on a result. What is result now? Result is nothing but the “result” of the analysis that coala performs. Currently there are only a set of actions that can be taken on a result. I have to change the action system so that people can define their own actions to be taken on a result. This part, I have figured out. I have to change existing result and action classes, write tests and update documentation for this.

Second part involves providing supporting bears which can give multiple fixes for a problem, which is currently not supported. This part might turn out to be little tricky, only because I don’t have a detailed plan for it. Bonding periods ends in couple of days, and I have to come up with a detailed implementation for this. So I will stop writing now and try to figure this thing out.

So anyways, let me start with my blog. I got to know about Google Summer of Code almost about one year ago when a student from my university Ishan Srivastava got selected into GSoC 2018 with coala. At that time I heard Google and thought “woah this seems 🔥”, but never actually tried to find out what is actually was because I was busy doing nothing. Then around November 2018, seeing a couple of my friends, out of sheer boredom I started contributing to coala. At the beginning trying to fix my commit message was not fun, but as soon as I picked up my first real issue I started enjoying the whole process. Just the thought of people sitting in different parts of the world working together on building something is unbelievable.

But I was soon left frustrated because there was much to change to solve that issue and John Vandenberg who is a maintainer of coala and was helping me solve this issue went MIA. I think he has not been active since a couple of months now and suddenly all the development in coala slowed down. At this point, I thought about not applying for GSoC and maybe doing an internship but just the thought of developing a website from some startup makes me nauseous.

One week before proposals were being submitted, I started working on my proposal, but the mentors for both of the projects I was interested were not active 😓. Then I got in touch with Mischa Krüger, who helped me throughout until the deadline. Honestly, without him, I don’t think my proposal would have been accepted.

Now that my proposal has been accepted I hope these 3 months are amazing. Also being active in open source community these few months has made me appreciate FOSS, and I have realized that getting accepted GSoC is cool not because of “Google” but because of contributing to open source is cool and everyone should try it.