I have written this blog to document some useful resources I found while participating for Google Summer of Code. This is supposed to be a live document, so feel free to share your resources of your choice as a comment, I will add yours :)

Starting with GSoC

• Getting a high-level overview of the different aspects of Software Engg — https://roadmap.sh/
• Free Udacity course for Git/GitHub — https://www.udacity.com/course/version-control-with-git--ud123
• For learning the implementation details of Software Engineering, I would suggest using Python for easy prototyping. It is quite easy to convert your ideas into code using Python — https://www.python-course.eu/
• KOSS Python workshop — https://github.com/kossiitkgp/Python-Classes
• For getting a list of resources that might help you learn a simple topic, I would suggest — https://github.com/sindresorhus/awesome
• Google Summer of Code FAQs — https://github.com/OrkoHunter/gsoc-FAQs
• Finally, I would suggest you go through the organizations — https://summerofcode.withgoogle.com/archive/2020/organizations/ where you can choose an organization based on your interest, and then you can dive into the ideas list of an org. This way you will need to research the different conceptual ideas used to solve the project and the tech stack associated with the project.

Choosing Projects for GSoC

• GSoC Org Frequency — https://github.com/thealphadollar/GSoCOrgFrequency
• GSoC Archive — Provides a rough idea about the type of projects that are selected — https://summerofcode.withgoogle.com/archive/

Personal blogs for GSoC participants

• https://blog.usejournal.com/how-to-prepare-for-gsoc-2020-6e20d0d46398
• https://thealphadollar.me/experience/2018/12/03/how-i-prepared-for-gsoc-18.html
• Some orgs have a good account for onboarding people to get familiar with the GSoC application process. Drupal has a good account for this — https://www.drupal.org/community/contributor-guide/reference-information/event-plan/google-summer-of-code/for-gsoc-students
• Awesome list for GSoC — https://realabbas.github.io/awesome-gsoc-roadmap/
• FossMec Account — https://github.com/FossMec/Awesome-GSoC-List/blob/master/README.md
• Hackernoon account — https://hackernoon.com/an-actionable-checklist-to-being-a-google-summer-of-code-student-47ca97e521f3

This post is a part of the series of my journal for spending my summers with Thanos. I would try to document my learnings and little tidbits of how I approached my project and any shortcomings that I would try to overcome in future time 😃

Special thanks to my mentors Bartłomiej Płotka and Kemal Akkoyun for mentoring me on working on a project under them. I am looking forward to an exciting summer with them!

Selection with Thanos

Thanos is an Open source, highly available Prometheus setup with long term storage capabilities. Before you start questioning what is Prometheus and what problem does Thanos solve, let me answer -

Prometheus is an open-source systems monitoring and alerting toolkit originally built at Soundcloud.

I heard about Thanos from a few of my college seniors, and while I was learning more about distributed systems, I stumbled upon CNCF, and how it provides a plethora of solutions for hosting applications on the cloud. Learning something practically comes from doing things, so I thought of implementing all of my learnings through contributing to an open-source project.

I was trying to appreciate each of the solutions provided by CNCF, and the monitoring and observability aspect really impressed me. This is how I landed up with Thanos and equipped with a warm and helpful community, I am excited to work with Thanos!

I also read through Khyati’s blog-post about Thanos, so I would highly recommend it.

Starting with Thanos

I started contributing to Thanos with some documentation PRs. I was impressed by the abundance of YouTube conference videos about Thanos and Prometheus, and totally understood the ‘what’ problem that Thanos and Prometheus are trying to solve. Here is a video resource to get started with Thanos and Prometheus.

I sent in a couple of documentation PRs and coupled with some PR reviews, I was up and running with Thanos!

Further thoughts

I was not able to be productive as I would have loved to be, because of the recent cyclone Amphan in Kolkata. While I was fortunate that my electricity was still up, my internet connectivity took a hit, and I have been barely able to connect with the outside world. I was also supposed to have a meet up with the other mentees, but due to bad connectivity, I had to drop the idea.

My connection has been better by the end of the week, so I guess I would be able to start with my work the next week without any issues.

I am looking forward to a meetup with my mentors and discuss my understandings and chalk out the plan for the project.

Until then, Ciao Adios!

Note : This blog post is heavily derived from one of the blog post from the codeforces website. I have basically explained the author’s approach and how it is different from the other approaches that is taken for calculating the articulation points and bridges.

So, what is an articulation point?

An articulation point is a point in a graph, which when removed from the graph results in disjoint graph components. A practical example of articulation points would be critical points in a network graph, whose removal might create a whole system shutdown.

This blog post takes a different approach while calculating articulation points in a graph. I have tried to explain the calculation of the articulation point in a graph using the author’s approach.

The DFS Tree

Those who have not heard about the DFS tree here is a short explanation about it. While I haven’t found an intuitive explanation of why the classical algorithms work for finding the articulation points, here I present you with an intuitive approach for calculating them.

DFS Tree is a tree of vertex traversal formed when we perform a depth-first search in a graph. Let’s say, we have a graph —

And we perform the depth-first search on it, we get the following tree. Note that the bold line refers to the path traversed by the dfs, and the light lines refer to the other paths that connect the vertices(later we will know that these are back-edges).

So our DFS tree looks like —

Now by looking at the DFS Tree, we can say that there are few light lines that are present. We can define them as a back-edge between a parent vertex p and child vertex u. If we get a path from p->u other than the edge pu, then we have a back edge.

I have drawn out the DFS Tree in a whiteboard to demonstrate the key facts in it —

We have broken down our traversal of the graph into a dfs tree, and in the dfs tree, we have the set of a vertex in a certain level of dfs. You can see the vertex 3and 9in level 2.

Now there are certain facts that we can observe before we move on to the articulation point.

• We can easily find the back-edge in a graph through the light edges in a dfs tree.
• The DFS tree simplifies the connection of a given vertex. Once we draw out a dfs tree, we can get a concise view without distorting the connection between the vertex. It is a simplified view of connections in a graph.

With these two facts, we can code up our implementation for calculating the articulation point. We can use the fact that counting the number of light edges in the graph(in the dfs tree) and return the no. of back edges in a graph. The problem is reduced into an intuitive one.

Note : The example graph out here, contains no bridges and articulation points. So don’t get surprised if you get zero bridges!

Calculating Articulation Points and Bridges

Calculating the number of bridges

As the dfs tree makes finding the articulation points and bridges quite intuitive, we now approach the problem of finding the number of bridges.

We can run the dfs in the graph problem, and then find the bridges either using the typical low and disc array approach, or by using a dynamic programming approach. Note that I am not a fluent coder in dynamic programming, but the approach discussed out here seemed quite intuitive.

So we start with two arrays — lvl and dp. The lvl array is for calculating the level of the vertices in the dfs tree. The dp array stores the state for each vertex about the number of edges. Before formally defining the dp, let me approach the recursive solution.

At each level, we have the following tasks —

• Calculate the level of the vertex.
• Calculate the number of back edges in the given level for a given vertex. Actually, the level of the vertex doesn’t matter, we just want to calculate the number of back edges for a given vertex.

The first one is quite simple :P. The second one is a bit complex, so let me break it down as follows -

• We want the number of back-edges for a given vertex. We can start with the leaf vertex, which has no children. Any edge going upwards is counted.
• Also, any back edge that is going downwards is subtracted, as we want only the back edges going upwards.
• We might also need to take care of the number of back edges in a subtree if the vertex is not a leaf vertex. So we add the number of back edges for the subtree.

Now we have a recursive relation for each vertex —

count[v] = #back edges going up + #total back edges in a subtree — #back edges going down.

Here, we can use dynamic programming for using the results computed for the child. Here we might double count the number of back edges for a given vertex, so we can reuse the number of back edges from the child.

So we use the following dp relation —

dp[parent] = #back edges going up + Σdp[childs] — #back edges going down.

Now how to calculate the #back edges going up and down? Fortunately, we can use the lvl array. We have three cases —

• If lvl of the unexplored vertex is NIL, we can initialize the child’s level as 1 + lvl[parent].
• If we encounter a vertex that has been visited, this means we have a back edge, and we need to check if the back edge is going upwards or downwards. If the lvl[parent] > lvl[child], we have a back edge which is going upwards, and we need to add the total back edge by one, or dp[parent] += 1.
• Similarly, if we encounter a vertex that has been visited, this means we have a back edge, and we need to check if the back edge is going upwards or downwards. If the lvl[parent] < lvl[child], we have a back edge which is going downwards, and we need to subtract the total back edge by one, or dp[parent] -= 1.

We also need to subtract the parent-child edge, as we are counting it again.

Calculation of Articulation Points

For the calculation of articulation points, we can re-use the dp array. Since dp array represents the number of back-edges for a given vertex, we can use the fact that an articulation point will have no back edge and its descendant subtree will also have no back-edges. So we can insert those vertices in a set of articulation point whose dp[i] = 0along with its parent.

Finally, I have drawn some explanations for the above approach and computed some values for each vertex. The best way to understand them is to draw out and see for yourself. Until then, Ciao Adios!

For those who are geeky and want to see the PRs submitted…

Here is the link where all my PRs for completing the project are present.

Google Summer of Code (GSoC) is an online, international
program designed to encourage university student participation in open source software development.

Details of my Organisation and Project

Before I start writing my report, I would like to thank my mentors Daniel Ryan and Stuart Mumford. They have been quite helpful in guiding me through the project, and have been quite responsive. Special thanks to Nabil Freij, for guiding through the project here in SunPy/NDCube.

NDCube is the fundamental class of the ndcube package and is designed to handle data contained in a single N-D array described by a single set of WCS transformations. NDCube is subclassed from astropy.nddata.NDDataand so inherits the same attributes for data, wcs, uncertainty, mask, meta, and unit. The WCS object contained in the .wcs attribute is subclassed from astropy.wcs.WCS and contains a few additional attributes to enable to keep track of its relationship to the data.

My GSoC project was under OpenAstronomy, and NDCube is a SunPy affiliated subpackage for handling ND Data arrays and perform data-analysis on them.

NDCube is a SunPy affiliated package for easily dealing with ND-Data cubes along with convenience method that allows the data cubes to be sliced, attach meta-data to it, and easy to use plotting methods, to visualize an ND-Data. It uses SunPy’s visualization to plot more than >2D cubes and provides sliders to shift the different dimensions, so even if users are using only 2D dimensions at a time, we can still leverage the other dimensions.

My project with NDCube was to port the internal API to match all the proposals laid out in APE14 and make sure that NDCube works in the same manner as it was working. The project was particularly interesting because I had a first-hand chance of interacting with API designing and how the different patterns were used to implement that. NDCube uses FITS-WCS to interact with, but APE14 leveraged the NDCube to use any WCS object implementing all the base methods laid out in the proposal. This was really exciting and I had a chance to use gWCS along with FITS-WCS in NDCube.

Blogging and details of my work

My weekly notes about my progress have been documented in my blog. Feel free to check out and suggest changes if needed.

Breakdown of my project

As described in my proposal, I had broken down my project into three parts —

• Porting NDCubeBase to use APE14
• Porting NDCubeSequence to APE14
• Support plotting in NDCube

All the associated PRs have been blogged in the PR post that I made earlier. Feel free to check them and gauge the progress that I made.

Some Visuals associated with my project

My Experience with working with NDCube/SunPy

Right from the start, I was really interested in working in SunPy, because of its amazing community and responsive mentors which I had planned to learn from them. The mentors were really helpful, right from designing the proposal to implementing them, always filling out on potential hurdles and rescuing me out every now and then.

I decided to list out the tasks which could not be completed, as the rest of the checkpoints were achieved successfully.

Here are some tasks which I had planned but could not be done

• Writing gWCS test-suite for NDCube — This was an optional part but having spent time with the code-base a lot, I realized that this could be done in a short time. However, this being an optional part, got pushed right at the end, and eventually had to be dropped off from the weekly tasks. I have planned to complete it after GSoC, so it remains on top of my priority list.
• Completing plotting of NDCubeSequence — I had completed almost all of the tasks as I had planned in my proposal but remaining one — Completing the plotting for NDCube Sequence objects. I had made the PR, but on close digging with the codebase, I realized that the master codebase was buggy, and a bug fix was needed to be made before resuming my porting. I made the PR, and after consultation with my mentor, we decided to drop the priority for the bug fix and just concentrate on my porting. I made a PR but it remains open till the bug is fixed in the master branch.

My Experience with Google Summer of Code

GSoC had been an integral part of my sophomore life, as it was something that I wanted to try out, with the associated perks and the hyped-up( but true!) steep learning curve. I had started my contributions right from January when people are unsure with the organizations and the type of projects that they want to commit to for the rest of the summers. I chose SunPy because of its fantastic community of developers from whom I learned a lot.

There was blogpost by NumFocus which highlighted my learnings during GSoC, so I would be sharing some unique points (not share the old ones :P) that highlighted my learnings —

Make sure you have a good understanding of the subparts of the project

I have had some moments where I just went about my tasks without having a solid understanding of them. I had to revert back to understand it again, so I recognized my shortcomings after my first evaluations and made sure that I had a solid understanding of the problem, rather than diving into it, without understanding the what and why of the problem.

Make sure you have some backup tasks to fall back upon

I have had moments when my work progress dried out, but talking with my mentor(s) and having some backup tasks did help me with my case of sitting idle. This turned out to be crucial in the last few weeks, as I had little to no time of starting out on a new feature. Thanks to my backup tasks, I had to carry forward them rather than starting them from scratch.

Make sure you have fun

Well, this depends on org-to-org, so I would not consider it as a universal fact. I had fun in interacting with the weekly community meetings arranged in every Wednesday. Other developers were quite helpful and curious about the progress of my project, and I was really happy to share the progress of my work.

GSoC is surely an experience of a lifetime, and I would suggest everyone who is enthusiastic with Open-Source and want to develop industry graded software, then GSoC is the right place.

Ciaos Adios!

This blogpost deals with all the PRs that were merged/opened in NDCube/ SunPy / Astropy for completing the project.

NDCube

The PRs were filed according to the tasks allotted in the task-tab of GitHub

Merged PRs

• PR for supporting APE14 for NDCube2.0 — Link
• PR for getting pixel_edges along with pixel_values in axis_world_coords — Link
• Support plotting to use pixel_edges instead of pixel_values — Link
• Added a new build astropydev in azure-pipelines.yml file — Link
• Fixed the failing `axis_world_coords` after a NDCube is sliced — Link
• Support 1D plotting in NDCube using APE14 — Link
• Support 2D plotting in NDCube using APE14 — Link
• Fixes the bug associated with axes_coordinates — Link
• Update the ape14_rewrite branch with the master — Link

Open PRs/Bug Fix PRs that needs to be merged

• Support 3D plotting in NDCube using APE14 — Link
• Support plotting in NDCubeSequence using APE14 — Link
• Added tests for gWCS in NDCube — Link
• Fixes a bug associated with axes_world_coords for APE14 branch — Link

SunPy

Merged PRs

• Added APE14 support in SunPy visualization — Link
• Shifted the axis for calculation of edges_to_centers for LineAnimator — Link
• Reverted the return arguments for ImageAnimatorWCS example — Link

Astropy

Merged PRs

• Corrected the message to work with None values in world_axis_physical_types — Link
• Implement support for APE14 WCS in WCSAxes — Link

This blog post deals with the entry of tasks that I did for the 13th week for the project under Google Summer of Code 2019.

Writing tests for gWCS

I started working on writing up test cases for gWCS and after having a discussion with Cadair, I thought of keeping this task on hold. I started with some cases but then Cadair advised me of getting the plotting code up and running.

Working out the NDCubeSequence — II

I had earlier made some progress with NDCubeSequence , so most of the tasks were finished as far as porting to APE14 was concerned. I started modifying the tests of NDCubeSequence and potentially opened a can of worms(or bugs!). Since I had a good understanding of the plotting code of NDCubeSequence I started fixing the areas where the conflict of data type between the old and new API was visible.

I sent a PR, but to my dismay, there were some issues with the plotting of NDCubeSequence in the master branch that wasn’t working as expected. I had a discussion with Dan my other mentor, and he suggested that I should leave the bug as it is, and should focus on wrapping up my task.

Wrapping up the project

The project was mainly changing the internal API of NDCube, so it required little to no mention in the public documentation. The change of API, however, had some changes in the docstring, so that has been worked upon.

I had a joyous time in working with my mentors, particularly Cadair , because of his bubbly nature and ability to simplify doubts for me. I will soon write up a final report on my project, and how it is working.

Until then,
Ciao Adios!

Link to my previous post

• [Week 12] — Approaching the dusk — I: Link

This blog post deals with the entry of tasks that I did for the 12th week for the project under Google Summer of Code 2019.

Getting PR 189 merged

This week was quite crucial as I had, in my earlier posts, tabulated out the list of tasks, which would roughly end my tasks associated with my GSoC project. Fortunately, my mentor Dan found out time to review my PR. He suggested some changes which I obliged and made the changes on the fly. This was crucial as I had already started playing with gWCS earlier, but due to the availability of Dan I had to revert back to the blocking work of plotting PR.

There were some nervous moments when Dan suggested that some parts of the plotting was not working as expected, but then agreed that there are far more changes that needs to be done before we can push NDCube, so he suggested me move forward with other tasks, and labelled it out of scope of GSoC. I finally got my PR merged, so it was small win for me.

Rebasing the ape14_rewrite branch with master

After the plotting fiasco was finally solved after 2 months, with the PR 189 nailing the coffin, I had to then rebase the changes in the master onto the ape14_rewrite branch. This seemed to be a herculean task, but after asking Cadair for some advice, he suggested that merging/rebasing is the only option and that I should do it complete peace of mind.

I started out with the rebasing, but there were lots of merge conflicts that needed to resolved. I solved each of them, and pushed the changes to GitHub for crosschecking the changes and whether it made any sense. I had no luck doing it on the first try, but after several iterations, I finally got the rebasing working for me. This was really challenging but at the same time, it got over much earlier than I expected.

Working out the NDCubeSequence

I had worked with NDCubeSequence quite before so I lost some of the knowledge of the workings of it. Fortunately, I had the notes of Dan who explained about the inner working of the plotting of NDCubeSequence , so I referred it. I started with changing the older methods of WCS with the APE14 ones, and at the same time I checked if the plotting was working as expected. This was a tedious process as the plotting depended on all of my previous work, and if I catch any bug due to the previous work, I may have to fix it before moving forward.

Learning gWCS

Cadair had earlier suggested me to complete the tests for gWCS and we had discussed the approach we might follow to write them. I started reading through the documentation of gWCS and started playing with some of the examples, before it might make any sense to me. Cadair also suggested some conftest.py files which contained some examples of gWCS which was quite useful for me to understand the framework of gWCS and how it was different from FITS-WCS.

I started working on the helper method which would help me in getting the gWCS object out of FITS-WCS. I had coded up the logic, but I had to write up the function. After writing the function, I tested it with existing FITS-WCS, and it was working great. This was really great, as I was making good progress.

Tasks for the next week

Phew! This was one of the busiest weeks of my coding period. I didn’t intend to push this close, but life happens so we must carry on with the work rather than criticizing our past.

The last week remains the week to wrap up my project, so here it seems my 2 tasks that need to wrap up —

• Writing tests for gWCS.
• Writing tests for NDCubeSequence plotting.

Link to my previous post

• [Week 11] — Fixing the dreaded bug — Link

This blog post deals with the entry of tasks that I did for the 11th week for the project under Google Summer of Code 2019.

Working on the APE14 in astropy plotting

I had been working on the astropy branch, so I had been regularly pushing bug fixes to it, customizing the code, so the new support works for NDCube as well. I had sent a PR for supporting plotting for SlicedLowLevelWCS, but astrofrog the writer of the astropy PR suggested me to shift that into his PR, such that the git history remains elegant. I modified the PR and sent it.

I also had issues with SunPy not supporting APE14 methods in their master branch, so I sent a PR adding one. This was an easy one, so got it merged quite fast.

Merging up the PR176

Well, this PR has been discussed quite a lot of times, such that it deserves a separate blog post about how much effort had gone into it for getting it merged.

I had worked on this PR earlier, so after discussing with Dan about the plan of course of action, I decided to fix the corner case, that was creating the issue. I sent a PR to SunPy, and asked Dan and Cadair to review them. PyAstro was arranged this week, so it was quite hectic for them to do a code review. Somehow, Dan managed to take out time to review both of them, and I was swift enough to make the changes on the go so that the PR gets merged as fast. After some nitpicking and some conceptual errors :P, we finally agreed to a point that the PR was fixing all the bugs that it was intended to do so. This was a huge moment for me, as I was finally able to get it merged, after a lot of traversals. Thanks Dan for taking out the time, as I started to work on the next bug fix, associated with axes_coordinates for plotting.

Planning up for writing the test-cases for gWCS

This was something, that I wanted to discuss with Cadair, for I wanted to divert my mind from plotting and get something else done for NDCube2.0. I had the goal of getting the test-cases covered for NDCube so I thought that why not get it done now, before dealing closing the plotting. My progress is blocked with this PR, so I would like to get this merged before it closes the bug saga for plotting in NDCube. I will then have to merge the master with ape14_rewrite so that seems to be challenging for me.

Potential roadblocks before the project gets completed

This seems to be a rough estimate for me regarding the tasks that I need to cover before the project gets completed —

• Getting PR189 merged
• Merging the master with ape14_rewrite.
• Completing the plotting for NDCubeSequence.
• Writing tests for gWCS.
• Writing documentation for the revamped portion of NDCube.

Only the 3rd point is loosely coupled with the rest, as the others can depend on the previous ones to be completed before some work can be done. This seems frustrating, as even though 4 tasks seem to be left, these are quite small ones, which can be completed within a week. I am keeping my fingers crossed because once the 1st one gets merged, I can breeze through the rest of them, so I really hope that Dan reviews the first asap.

Tasks for the next week

My objective would be to complete the testing of gWCS which seems to be loosely coupled with the rest of the objectives. I would also wait on Dan reviewing PR189, so I would really hope that this gets done. If the test-writing turns out to be short, I would then switch to completing the plotting using APE14 for NDCubeSequence.

Link to my previous post

• [Week 10] — Dan is back! — Link

This blog post deals with the entry of tasks that I did for the 10th week for the project under Google Summer of Code 2019.

Discussing plotting with Dan!

This week started with me working through the 2D and 3D plotting code of NDCube. I had a discussion with Dan and Cadair regarding the telecon for the plotting code. I was really fortunate that somehow, Dan arranged out some time from his busy schedule to discuss the plotting code from SunPy.

I had worked on 3D NDCubes and modified the tests, to move forward with the tasks. On Wednesday, we had the telecon, so here it goes.

Telecon with Dan and Cadair

This telecon was much needed for me, more than the mentors to get a knowhow about my project, so I was apparently quite excited to meet and discuss some portion of code which I had researched a lot. After SunPy’s weekly community meeting, which takes place at 16:00 UTC(which anyone is invited for), I had a talk with Dan and Cadair. Phew!

We discussed the intricacies of how the LineAnimator of SunPy works, and I discussed the potential edge cases, which I felt was not being dealt with, so I raised them before Dan. After brainstorming with Dan, we finally came to a point, where there were some issues with some of the edge cases not being dealt in LineAnimator so, I discussed with him that I shall send a PR fixing those, and Dan agreed to review it, since Cadair does not like the plotting and Dan had re-written the entire LineAnimator code of SunPy, so it was fair for him to review.

Working on Astropy

Since my plotting for NDCube using APE14 was using all the features that were being supported in this PR, I sent a couple of PRs, fixing some weird edge cases that were being raised when I was working with plotting. It was pretty difficult in segregating the errors being raised due to the plotting bug or due to the APE14 support PR in astropy. I was working on a local branch that had fixed most of the bugs of plotting in NDCube so it was much easier for me to understand the context of the error, that was being raised.

I submitted two PRs fixing them, and astrofrog, the writer of the PR to support APE14 in astropy was quite helpful in getting it merged.

My views

This week, to be honest, I had done work to my heart’s content, and I had some progress to show. Having a telecon with Dan was very much re-assuring for me, as it had become really difficult for me to gauge my progress, and the hurdles that emerged was confusing me, whether I had some shortcomings from my side, or my mentor was really busy(which he was :P).

Tasks for the next week

My list of task that I would like to get it completed would be to complete PR176 and fix the bugs that haven’t resolved for a few months. I also need to back-port the changes back into ape14_rewrite branch in NDCube, so I also need to discuss them with Cadair about different possibilities to do so.

For those who were wondering about the title of the blog-post…

The title of the blogpost was inspired by my previous post(also I was lazy to think a new one :P). Also Dan had been outside the scene for so long, so it was quite a long time before he had a review about the work done.

Link to my previous post

• [Week 09] — Cadair is back!— Link

This blog post deals with the entry of tasks that I did for the 9th week for the project under Google Summer of Code 2019.

Crawling through this week’s targets

The target for this week was really clear for me — Get the bug fix PR merged, and hop onto something else. Sounds simple? Nah!

In spite of dedicating a week, I was still not able to get the bug-fix completed, as it later led to opening to a can of worms(bugs)!

Earlier, I had finally made some changes to the plotting code, and voila it was working. Note that I was able to understand most of the plotting semantics, and I was mostly convinced about my bug fix that fixed the two failing tests. This was a moment of sigh for me, as I finally solved the issue which was stagnant for a couple of months since I made the PR.

Striking the reality

However, the reality struck, as I was getting my code merged, my mentor @DanRyanIrish, reviewed the code and tried out a few examples from the docs( which in hindsight I should have done that!) which were failing drastically. This was quite scary for me as it seemed that all those week’s effort was gone into waste, and I was back to square one.

After recovering from the initial shock, I decided to go through the issues that Dan was having, and on close inspection, it was seeming to me that those were something which wasn’t something from my code. On trying the doc examples, the examples were breaking in an un-premeditated way, which was shocking and at the same time, a bit reassuring that my rewrite wasn’t creating an issue which was present earlier.

I had a discussion with Dan and he asked me to file an issue, as it was quite different from the issue which I was solving.

Cadair is back!

@Cadair is the name of my other mentor, Stuart Mumford. He went for few weeks of excursion, and I was quite happy that he was back for SunPy. I had been working closely with him for the past few months, so I was really waiting for him to arrive back.

I discussed my issue with @Cadair and he suggested that we should hold a telecon, and I should get some insights about plotting from Dan. This was quite reassuring, as it can pretty become scary on managing stuff all alone.

@DanRyanIrish has been quite busy, so it was really difficult for him to be active all the time. With Cadair back in the scene, I discussed with him about stuff that needs to be worked upon. We decided to skip out the animate-1D plotting part of NDCube until Dan is free, and start with the 2D plotting.

Back to track

My previous bug isn’t fixed, but I have moved to tackle the 2D and 3D plotting. I have wasted around 3–4 days playing the waiting game, as the period between pushing the PR and getting reviewed took some time, and I was clueless about the progress. In the hindsight, I should have started with another task, and rather than playing the waiting game.

I have made two PRs for 2D and 3D plotting, and those are still quite basic ones, but I will add more tests as I face any sort of issues. Currently, at the time of writing this post, I have incurred a bug, which I am discussing now 😛.

Tasks for the next week

For the next week, I have a telecon arranged with my mentors on a Wednesday, so hopefully, I can get insights about the plotting code. I also plan to work out the present bug that I am facing, so that would be next week’s priority tasks.

Link to my previous post

• [Week 08] — Gearing up for the plotting — II — Link