By Akshay Padte (@akshay-99)
Over the course of this summer, I worked on extending the Friendly Error System of p5.js with the help of my mentor Stalgia Grigg. The Friendly Error System, or FES for short, is a component of p5.js designed to help new programmers with common errors as they get started with learning. It detects common errors and mistakes and provides helpful messages to help the user resolve these.
The major goals of this project were:
- Improving the efficiency (speed and size) of the entire system.
- Fixing bugs with the existing FES
- Extending internationalization to cover the entire FES
- Adding functionality to detect errors spelling and capitalization.
- Adding functionality to capture and simplify global errors
I had been a p5 user for more than a year and had come to love it and rely on it a lot for several personal projects. I started contributing to p5 in around February this year, picking up issues and helping resolve them. In this brief period, I got to learn a lot about the inner workings of p5, how it initializes, how it builds, how the tests run, how different components work together, etc.
One major work done before GSoC officially begain was actually unrelated to the FES project:
Fixing saveGif()
Issue: #3871
Pull request: #4339
saveGif stores a GIF from memory to a file. The problem was that the resulting GIF was often much larger than the original. The main cause behind it was that the GIF property of transparency was being overriden. Transparency allows us to indicate when a pixel in the current frame won't change as compared to the previous frame. We mark all transparent pixels with the same color code. So in actuality the resulting GIF is this:
The LZW lossless compression algorithm can easily compress these large patches of repeating values together, saving a lot of space. But obviously we can't have this broken GIF as the output. So we must set the disposal value of frames that use transparency to 1 (do not dispose). The resulting GIF is hence:
I kicked off the summer by addressing the issue of speed and size. The FES has a component called validateParameters(), responsible for checking if the arguments passed by the user are correct. It does this by matching the arguments against a file auto-generated from the inline docs. Earlier, this file was imported directly into the main library for the FES to use, but it also has a lot of information that is not needed by the FES which increases size unnecessarily. Pre-processing this file to keep only what was needed helped reduce the size of the final built p5.js library by around 25%.
Another issue was speed. validateParameters does a lot extra work before the actual function is executed. Sometimes, as seen in this performance test, it would slow down a function by up to 10 times. My initial assumption to speed it up did not work so I played around in chrome dev tools to figure out what was actually happening. I learnt that most of the time was spent just trying to figure out the nearest matching overload intended by the user, and that this entire process happened over and over again if the function was called multiple times with the same arguments. I addressed this with a trie like data structure [1], where each node represents an argument. Thus if a function is called again with the same sequence of arguments, we don't need to run the entirety of validateParameters. This not only improved the speed but also prevented the FES from flooding the console on repetitive calls of the same function.
There was another issue which caused validateParameters to ignore the last undefined argument passed to function. This sometimes used to cause confusing and inaccurate messages. Fixing this was pretty easy and only involved one line of change.
Moving on. There was an issue that if one p5 function called another p5 function, validateParameters would run both times. For example, the function saveJSON() needs to call saveStrings() to do part of its work. It forwards the arguments it receives to saveStrings(). This meant that if arguments were wrong when calling saveJSON(), we used to get two messages: one for saveJSON() and one for saveStrings(). But the user never called the latter in their code! This could lead to confusion.
To fix this, one can take a look at the stack trace. We need to answer "was the most recent p5 function invoked from another p5 function?" If so, we don't need to display a message even if the arguments are wrong. I used another library stacktrace.js, to help with this. Analyzing stack traces was extensively employed later-on in the project as well. We'll come back to it later.
As a next step, internationationalization support was added for validateParameters messages and the language of some of the messages was simplified [2]. There were a couple of other small problems that were also fixed in this phase. You can see them in the full list of pull requests.
PRs in this phase: #4561, #4580, #4590, #4606, #4613, #4629
I had ideas for two new features to make the FES more powerful.
The first was to add a spell-check kind of system to the FES. Beginners often need time to understand the various naming conventions commonly used in programming, such as camelCase for identifiers, CAPS for constants, etc. And so, capitalization and spelling mistakes are very common, such as writing createcanvas() instead of createCanvas(), colour() instead of color(), etc. These kinds of mistakes are relatively easier to resolve, as the browser would display an error pointing to the function call. But if someone misspells a p5 entry point function (which has to be defined by the user), such as by defining preload() as preLoad() (I learnt that this is a very common mistake), p5 wouldn't detect it and the sketch would fail silently. It may take a lot of time to debug this simple mistake.
Case-insensitive Levenshtein distance, calculated by the Wagner-Fischer algorithm was used to automatically detect these mistakes in user-code. The check would run on two instances:
- Whenever a reference error is thrown (happens when a predefined function is called with a wrong spelling or capitalization)
- When p5 is initialized, to detect mistakes in naming any entry-point functions (setup, draw, preload, etc.)
Here are a few example messages from this feature :
The second new feature was Global Error Catching. This meant analyzing the errors thrown by the browser and trying to match them up with helpful explanations was to solve them.
The first step was to come up with a way to detect and classify errors. Detection was easily possible with the help of an error listener. To classify the errors, using a regex match against a prebuilt lookup table was settled upon. The idea was based on the fact that web browsers use template error strings to generate error messages. This means that for a given browser, all error messages of a particular kind would have a consistent structure (This is pretty obvious I guess but I wanted to be sure. So I went through the source code of Chromium to confirm this 🙂). We can have our own template strings with placeholders [3] which are then replaced with regex matching sequences ( like ([a-zA-Z0-9_]+) ), and then the result is matched against the error message to detect what kind of error this is. The regex sequence also helps to extract relevant details. For example, take a look at this sketch:
function setup() {
let a = 5;
}
function draw() {
let b = a + 5;
}It shows a very basic mistake with scope that a beginner can make. The error shown is:
While the browser error message aims at being concise, the FES message aims to explain the error as much as possible and also provides links which have examples to fix this kind of error. This is more helpful to those who have just started learning to program and have not yet gotten used to deciphering error messages.
Another distinction to be made was between errors in user-space and errors that happened inside the library. These could be differentiated by seeing their stack trace. Moreover, it's possible to simplify the stack trace itself to only include user-defined functions.
Here's an example of an error that happens in library space:
The FES filters out all the internal details from the stack trace, making it easier to understand.
PRs in this phase: #4643, #4670
Sticking with the original proposal would have meant that this stage would involve adding even more features. However, over the course of the project, I realised that those were not really a priority for p5 at the moment and that their implementation would take longer than what was previously expected. I discussed this with my mentor and we agreed to change the plan a bit. In this stage, I worked on detaching translation files from the library and hosting them online on a CDN, and on more thorough testing and documentation.
p5 uses a separate translation file for each language, and though presently only the English one is fully complete, it has grown a lot in size over the course of the summer (and is likely to grow more in the future). As more and more languages are added, bundling all of them into the library may have been imprudent. It was discussed that these could be separately hosted on a CDN and p5 would then fetch the required file whenever needed. The build process was modified to remove the translation files from the final library. These files were then hosted on CDNJS and jsDelivr.
The internationalization code was modified to fetch translations from the internet, with the English file still built into the library as default and backup.
During testing, I came across an issue that global error catching did not run when running locally without a local server. I came up with a fix but it involved calling all user code through an extra layer of wrapper function. We discussed this and it was finally agreed that the benefit of fixing the issue was not significant enough to offset the negative effect on code readability this would have.
The final week of GSoC involved documenting all the changes that were made as part of this project.
PRs in this phase: #4701, #4709, #4726, #4730 (closed), #4746
-
All of the pull requests made as part of the project can be found here:
https://github.com/processing/p5.js/pulls?q=is%3Apr+author%3Aakshay-99+created%3A%3E2020-05-04+ -
All of the issues opened as part of this project can be found here:
https://github.com/processing/p5.js/issues?q=is%3Aissue+author%3Aakshay-99+created%3A%3E2020-05-04+
I really enjoyed working on this project. I learned a lot of new things. I would like to thank my mentor Stalgia Grigg for all the guidance and feedback throughout the project. I would also like to thank the entire Processing community on Github for helping me with ideas, suggestions, views, etc.