Jun 21, 2014

GSoC 2014 midterm already?

I cant believe that its been more than a month into GSoC 2014 and nearly two months since the results were announced. The last one month has been an enriching experience for me - meeting new people and learning new things. This post will try to give a quick overview of what I have been upto in the last month.

Accomplishments

As mentioned in this earlier blogpost, I began Google Summer of Code 2014 by initiating and completing a human test framework for IDLE. It was a good beginning and I did not face any difficulties in the first two weeks. It got me going in the right direction.
Once human test framework was completed, I began extending the unittest framework for IDLE. In the next two weeks(week 3 and 4), I wrote tests for the following modules - HyperParser, ParenMatch, AutoExpand, ConfigHelpSource, ReplaceDialog,, UndoDelegator, and various configuration files.
I also attempted a solution to make the IDLE title bar configurable by the user. The proof-of-concept file can be seen here. I also began work on rectifying issues related to IDLE's keyconfig and keybinding, though it has quite a long way to go, before it is going to be completed.


In this week, I began and completed work on integrating linenumbering to IDLE. Related to it is, breakpoints integration feature for IDLE, which is almost complete. This subproject, though fully functional, does require few polishing touches to it.
Linenumbering and breakpoints in IDLE
Roadblocks

As mentioned earlier, the first two weeks was relatively straightforward for me. The first major roadblock for me was in the form of a reference leak(refleak) while writing tests for UndoDelegator. I spent a good part of the day *understanding* what a refleak was in the first place. The next couple of days were spent painstakingly trying to identify the reason for the reference leak. I did finally manage to trace the leak and fix it. (Most of the credit for this goes to Victor Stinner, author of tracemalloc). In one way, I feel happy to have encountered this bug - I learnt many trace tools like tracemalloc, which I would never have known otherwise.
Another roadblock was a memory leak when adding linenumbering to IDLE. This bug would cause IDLE to continuously increase its memory footprint every time *any* action was performed - insert code, delete code, scroll window, you name it.. I was initially worried that there was something inherently wrong in approach. After a few days, I detected the cause for the leak, was nothing to with my approach. Fixing the leak was simple enough, once it was detected. I felt good when I was able to debug it myself.

Looking forward..

The next couple of days after midterm, will be spent in polishing IDLE's linenumbering and breakpoints additions. Once it is complete, focus will shift to integrating an API to allow IDLE users to integrate any 3rd part code analysis tool.

Ciao.

No comments:

Post a Comment