Colby Peck - Gateware Week 15: Beaten by Apple

This week was mostly spent trying to fix GWindow’s mac implementation. I wasn’t able to figure out a full fix, but I advanced the debugging process a fair bit. I patched the exception that was causing the tests to fail and crash, but a new issue arose: ghost windows. The tests were creating grey, empty windows that weren’t closing until the UT  project finished. I narrowed down the issue to how we’re handling fullscreen windows - whenever a fullscreen window is created or a window is reconfigured to become fullscreen, it leaves behind a ghost window. 

Some of these windows seem to be created from a timing issue - if you create a fullscreen window but delete it before it has the chance to finish the fullscreen animation, it spawns a ghost window. This can be fixed by delaying the deletion until the window is finished animating. But other times, even if the window is given ample time to finish the animation it still spawns a ghost window. I met with Lari yesterday to pair-debug the issue, and we decided that it would be a better use of the month I have left before graduating to work on the GTemplates pipeline instead - this mac issue is going to require a deeper understanding than I can get quickly, and we want to capitalize on the fact that I’ve already become familiar with Gateware’s CI/CD process.

So I did what I could to leave the GWindow mac problem in a better state than I found it - I made sure to document our findings on the Gitlab issue card and I set up the branch to clearly recreate the problem. Hopefully whomever this task is assigned to in the future will have an easier go of it than I have.

Colby Peck - Gateware Week 14: Documentation and GMatrix wrap-up

I took this week a bit slow, finishing up the pipeline refactor took a bit out of me. So far, I’ve spent this week mostly on wrapping up the refactor of the GMatrix tests. I finished those up yesterday with a small fix to the source code (MakeRelative only works with invertible matrices, but it was returning success and garbage values if given an non-invertible matrix; it now returns failure). That branch is now ready to be merged into master. I spent this morning writing and updating documentation for the pipeline: HOWTOBUILD.txt and HOWTORELEASE.txt got updated, and I added a HOWTOUSETHEHEADERLIST.txt just for good measure. HOWTORELEASE.txt now contains information on what changes might unexpectedly break the newly automated release process (essentially, moving or changing directories or some specific files will break the release process if the pipeline isn’t updated).

My next big task is going to be getting Gateware to work on the latest mac OS. My last post wasn’t quite right; Gateware is compiling, but GWindow is failing some tests. It seems to be a timing issue related to GWindow’s thread handling. 

Ah, yes, multithreading. My favorite.

Lari let me know that he’s going to be taking a vacation in August (I can’t blame him, that man works hard). So I’m going to be taking advantage of his presence to help me troubleshoot this mac stuff while I still can (misery loves company). After he leaves, I’m going to be working on GTemplate’s automated pipeline. I’ve spent six weeks working on CI/CD stuff at this point, so I’m pretty comfortable doing it without Lari’s direct supervision.

Colby Peck - Gateware Week 13: A Light at the end of the Pipeline

 

The pipeline refactor is officially finished!

This last week has been very rewarding for me; I properly started work on this pipeline refactor 7 weeks ago, and yesterday Lari and I finally finished it with some repo renaming. The repo once called Gateware is now called GSource, as its job is to host Gateware’s source code. The single header compiler (and single header test project) has been moved out to a repo called GCompiler. The repo we temporarily named GRelease has been renamed to Gateware, and it now houses Gateware’s single header release as well as the relevant documentation, licenses, etc. 

Let me give you a tour of the new pipeline, starting at the inception of an addition to Gateware and ending with a new release (from the perspective of a Gateware developer):

You’ve come up with (or been given) an idea for an addition to Gateware; maybe it’s a bug fix, maybe it’s a new library or an addition to an existing one. You make a branch off of Gateware’s master branch. Every time you push a new change to your branch, the repo will automatically run your code through all of the unit tests on each platform. You can, of course, also run the tests locally. What’s important is that when you go to make a merge request, to merge your changes into Gateware’s master branch, all of the unit tests must pass before the merge request can be approved. You finish up your changes and make a merge request; all of the tests pass and your request is approved. What happens nest is the part I’ve been working on for seven weeks: after passing all of the tests on the master branch, GSource’s pipeline will then tell GCompiler’s pipeline to run. GCompiler clones GSource (using a shallow clone, if you’re curious), then compiles Gateware’s source code into a single header and runs all of the unit tests on that single header (it’s easier than you think to compile a broken single header from working source code). If all of those tests pass, it will then generate a fresh batch of documentation using Doxygen. After the documentation is generated, it will then take the new single header and documentation (as well as some license files and such) and push them to the Gateware repo, tagging the commit with an auto-generated version number. Finally, Gateware’s pipeline uses the version number from the tag to make a new release of Gateware.

In summary, the process of releasing Gateware has been fully automated! Once a merge request is approved, no more action is needed. Developers never have to worry about the single header, and Lari doesn’t have to manually make a new release.

There remains one small hiccup, though. The single header compiler is pretty good at its job, but it still isn’t set up to figure out dependencies and order the headers accordingly. I set it up to accept an external text file to sort the headers by, but developers will still have to manually edit this file and make sure the headers are ordered correctly. Ideally, the compiler would do that automatically (that’s one of the reasons we made compilers in the first place, after all), but that’s a big task that we’ve put off for now. We have a working manual solution, and tasks are more pressing. Did you know that Gateware doesn't compile on the latest version of mac OS? I do. I know it all too well…