I can’t believe three months went by like three days. It’s the last week of my Outreachy internship @GNOME and there is so much to say. For easy readability, this blog post will have five sections fear, growth, accomplishments, future plans and conclusion.
When I first looked at the issues to be completed within the course of the internship, I was scared of not being able to complete any by the end.
One can choose to go back toward safety or forward toward growth
All of this would have been more challenging without assistance from my mentor Philip Chimento who was very supportive along the way. He
- always answered the questions I asked as soon as possible taking out time to give detailed explanations
- encouraged me to stay positive and optimistic at all times
- gave me space and time to experiment with the project
- helped setting up informal career chats with people who had experience contributing to open source (this was the most amazing experience I had during this internship)
- gave me a lot of career advice
Communication has never been my strong point but this internship proved me wrong. There is so much I have learnt about being a better verbal communicator. There have also been great improvements on my listening and writing skills. This is probably because I wrote a lot during our Zulip chats and when blogging as well. The meetings with my mentor were verbal and visual and most of the informal chats I had went on with me listening.
Technically speaking, so much has been added to my basket of skills.
- I learnt how to write tests for the debugger
- and I can now review code
So far, I have worked on three issues. In subsequent paragraphs, I will be giving details about my contributions
- Adding the “full” option to the backtrace command
Basically, this option helps developers print details about the variables in a given stack frame. More information on this command is found on this blog post https://nasahnashdeveloper.wordpress.com/2021/01/18/my-journey-to-gjs-backtrace-full-option/
2. Displaying the current line of the source code while printing the current frame.
The first change I made was to print the source code on the line where the debugger was stopped. Before this, you could only see the frame number, the file name, and the line number. This addition helps users figure out where they are in the source without having to keep the file open and cross-reference the line numbers to their editors.This contribution can be found here https://gitlab.gnome.org/GNOME/gjs/-/commit/b19e75065ca4b6352af140a3fa2af018b4028083
Going further, since we were able to load the source code, it was also possible to implement a list command which will help in printing lines from a source file. The current implementation prints five lines before and five lines after the line chosen to give more meaning to this line. The code for this functionality is found here
Lastly, a set color option was added to the set command to let users choose if they wish to be printing with color or not. For now the bold option is available and different color codes will be added in future contributions. See details of this contribution here https://gitlab.gnome.org/GNOME/gjs/-/commit/d352aa9cd1849119d9b95bd64c0d66a6857a340a
3. Verbose Object Print Output
Currently, the interactive prompt prints an object like this [object object]. To workaround this, most people resort to using JSON.stringify(theObject) (which is usually a pain to remember and type) when they want information about the object. [object object] is the default output of the toString() method when called on a plain object, but most interactive environments (like Node.js and the browser console) give you more information than just [object object].With inspiration from Node.js and the need to improve on user experience, it is good to have a pretty print function that prints an object with more information about its property names and their values. The in progress contribution to this effect can be found here https://gitlab.gnome.org/Nasah-Kuma/gjs/-/commit/122c02ffadb6b43d68f5e68d22d009543b98c909#0383dbd3f0cc84e0cf5ff5fdf9c685903addae56 in the modules/script/_bootstrap/default.js file
After the pretty print contribution is merged, I will continue working on “Implementing a debug server so that GJS code can be debugged using the Devtools in the Chromium browser” that will be done by first requesting for a meeting with Philip Chimento and also talking with other members of the community so we can discuss on a good way to go about this.
This internship has been an eye opener revealing how much I can do as an individual to improve on the field of software development. GJS is just one of so many projects which needs maintenance and community support. If you are reading this post and wondering if you should contribute to open source, you probably should since it won’t only help the community as a whole but help you improve in particular. To contribute to GJS, follow the guide on this link(https://gitlab.gnome.org/GNOME/gjs/-/blob/master/CONTRIBUTING.md) and checkout the issues. If you are new to open source, it’s best to take issues tagged newcomer. If you feel that’s not such a good place to start, you can always suggest and create your own issues using the issue tracker.
Thanks for reading…