BugsDoneQuick practice report

Over the past two weeks, I've been steadily gearing up for the BugsDoneQuick stream I'm planning to run between July 6 and 13.

The basic concept of that is to be speedrunning solving open-source issues on-stream. As such, in addition to testing and refining my streaming setup, my practice included resolving a few issues in major open-source projects I love and use every day.

The test stream, June 18

I started off with confirming I actually have the hardware with which I can livestream at a decent quality. That happened on a test stream on June 18, right after I had set myself up with an account on MakerTube; a PeerTube instance that allows livestreaming.

A lot of the details of that stream are also covered in a previous article.
For the most part, I was busy setting up OBS and other software, as well as figuring out how to use both machines I had available: a laptop for encoding the video stream, and a desktop machine for CPU-intensive code compilation.

After I had set things up, I went ahead and started coding some changes to OBS related to getting PeerTube listed in the Auto-Configuration Wizard; though, after talking it through with OBS maintainers, and reading through a relevant idea thread, I realized integrating the two would be a lot more work, so I won't be the person to implement that, at least for now.

Unfortunately, I got to discover that I can lose the recording if I.. don't tell PeerTube to save the recording. Whoops—that's something I would need to not forget later, as no matter what happens with my live audience, recordings will be useful to share even after the event is over.

Practice run 1, June 23: Dolphin

On June 23 I held my first scheduled practice run. The goal was to see how it goes with a real issue and to see if any part of my delivery needs polishing. So, when the day and time came, for around 3 hours, I streamed myself fixing an issue with file names in the Dolphin file browser (which is the default file manager in KDE, the desktop environment I use on Linux).

The bug fix itself took about 2 hours and a half—you can watch all of it in the recording!

First thing was figuring out where the code responsible for the bug even is. I had a few viewers in chat trying to help guide me on the right path, but alas, I didn't see them until half an hour later, when I had just about found the spot.

Then, it was about figuring out why the issue occurs at all. The code, as most code out there, looked correct at first glance—and that made it somewhat difficult to spot the critical line of code where it was broken. Clearly, the issue was that Dolphin used one way of calculating the size of a piece of text when it tried to fit it on the last line (horizontal_advance()), while the code that draws the text used another way (QTextLayout)—which broke it into two lines.

I played a bunch with making sure the the right text is being measured, that font is passed correctly, and so on. I even opened up Qt's code (Qt being the library used for drawing), and tried, somewhat unsuccessfully, to track down the differences between the two ways of measuring text.
Eventually, I gave up on finding a better solution, and using the same code that the real text rendering used to check if the shortened text would break into two lines. It was slow that way, but at least it worked.

Finally, I looked back at the code's history only to spot something quite curious: the original code that calculated the size used a different function (boundingRect().width())! But later on, someone had changed the line to use the wrong function (horizontal_advance())! Experimenting with using the original function made it work, and after some looking around, it turned out this was just a case of a find-and-replace gone wrong—the person who was fixing an earlier bug ended up replacing one line too much.

And so, at the end of the two hours, I had... a single-line change, which was actually a reversion of an earlier commit.
Hoo boy. 😅

At least, the submitted code change was approved within 24 hours—that's quite fast!

The feedback I received after this first practice session was that my background removal was being distracting and that it was very hard to follow what I was doing as I speedran. To fix the first concern, I moved the camera off into another corner and left my original background as-is.
As for the second concern... I took a while to reflect about it, and figured I should be sharing more about what I'm doing at any given moment (say, reassigning variables, changing comments, etc.), and talk less about why I'm doing it—that way, people with a bit less programming background might be able to follow along, even if my thought process is focused on other parts of the activity.

Practice session 2, July 1: Forgejo

The next practice session was on July 1st; during it, I picked a few bugs and some Quality-of-Life features to implement in Forgejo/Codeberg. Forgejo is an open-source, self-hostable code "forge", similar to GitLab or GitHub; a web application for collaborating on software source code that has been stored in Git.

In particular, I wanted to implement a (supposedly) missing feature in Forgejo: the ability to download whole folders as a ZIP file. However, I wanted to practice speed-running multiple issues in a row—similar to the final streams next week are going to be. So, for that, I also picked a few other issues as well:

• Adding Interlisp support to the syntax highlighter, so it shows Interlisp sources as text, and not as binary.
• Fixing rendering of previews inside iframes, since it resulted in a JavaScript error and no preview shown.

For the Interlisp issue, a Forgejo maintainer had already helpfully suggested the exact part of the code that needed to be changed: the DetectContentType function that figures out whether a file is text, binary, image, PDF, or something else. In this case, I had to correct any file mistakenly assumed to be "binary" to be instead counted as a "text/interlisp" file, if it started with the right text ((DEFINE-FILE-INFO ), and did not have an LCOM extension (since, apparently, LCOM files are actually binary files that start with the same text).
The only tricky part was the need to pass the file name everywhere DetectContentType was used, since this was the first file type for which it needed to know the name of the file as well as the content—but with that out of the way, the whole bug fix took around an hour. Over in a breeze!

For the iframes issue, a lot of my 2 hours of fixing were taken up by reading the <iframe> documentation on MDN, in order to figure out why the preview iframe was counted as cross-origin.
The code that was erroring out needed to get the height of the preview so it could resize the "frame" containing that preview to match. However, since the preview was counted as not part of the same "website", the browser prevented the code from accessing any part of the preview—including the size! After some toying around with the iframe (and reading up on StackOverflow), I realized that the only way to get the size across would be to use window.postMessage-s. And from there, it was mostly a matter of wiring things up and polishing the code for submission.

Here, again, I browsed through the history of the offending piece of code to find when it was introduced, and if any change might have broken it since. And, to my disbelief, I couldn't find any version in which the old code had ever worked! Perhaps browsers at the time when the original code was written, have had a bug which allowed an piece of JavaScript get the height of an sandbox=allow-scripts iframe, but reading the documentation, that code should have never worked at all.

Either way, another 2.5 hours, another bug slain.

As for the ZIP download feature I was originally going to do, a quick look at the Forgejo interface told me that it was already implemented. So, instead of solving it, I instead found when it was solved, and submitted that as a comment to the issue.

For day two, again, I got a really quick response from the maintainers. The Interlisp change was merged right away, while the iframe fix got a few critical comments I need to address before it will be accepted. And, even better, one of the main developers of Forgejo commented on my post about the stream! I'm so honored! 😊 😊 😊 And glad I picked this project for some of my practice; think I might come back to contribute more once I'm done speedrunning.

I didn't get feedback from the second session. Instead, I got another lesson in avoiding technical issues. For some reason, the internet connection between me and MakerTube was really flakey that day; and the stream ended up chopped into like 10 individual 20-minute videos with roughly 4 minutes of footage missing between each pair. Which is.. a disaster; not learning the lesson from my first test stream, I wasn't recording anything locally, and just relied on the platform to record everything for me.

So, the "feedback" I can give myself is that I need to record locally, and have more control over the whole experience so that I can minimize Internet-related problems as much as possible.

For that end, I set up my own PeerTube instance up at watch.bojidar-bg.dev; and I'll be streaming there! 🎉

In addition, starting off the stream with explaining more about the project was fun, even if it didn't make it into the recording. I'll have to make sure I scour through project description beforehand, and not just go off of memory, however! 😅

Conclusion

But yeah. That's it for now! "Practice" is over, and the real live stream is starting on Sunday!

Honestly, I have no idea how much streaming for a week straight will change me. Perhaps, it just complement my oral communication studies at college—but perhaps, I would come out of it with a whole new perspective on life? I guess, it's to be seen.

And, if you want to see me live: feel free to join the stream, starting on Sunday (with a shorter stream at 10:30 UTC) and then going every day (at 8 UTC) for 6-7 hours through the whole of next week!

This is my 17th post of #100DaysToOffload. Expect more over the week, if I have the energy to recap and report things as they happen!