Task Breakdown:
| Task | Date | Duration |
|---|---|---|
| Fix timer code with Edd | 25/02/21, 02/03/21, 03/03/21 | 5 hours |
| Create JUnit tests for timers | 03/03/21 | 3 hours |
| Move around GitLab stuff | 02/03/21 | 30 mins |
| Weekly total | N/A | 8 hours 30 mins |
Weekly meeting takeaway:
In this week’s meting we addressed progress on last week’s items and have devised ways to split work more evenly as well as an investigation to find more potential work to do in the coming weeks.
Personally, last week was a bit rough and scheduling didn’t line up so I’ll get together with Edd to attempt to fix and publish a version 2 of the timers code.
Additionally, I’ll use this code to create some example unit tests with JUnit and also upload this to the repo so the other developers have something to go off of when they inevitably have to construct their own unit tests for the modules they are working on.
Finally the group have now realized things are in the wrong place in the GitLab, so all currently uploaded material is to be moved to appropriate locations on an individual basis.
Fixing timers with Edd:
After some lengthy talking with Edd I was able to get a good idea of the intention behind how the timer is intended to be implemented. To summarize, the timer is intended to be a self contained item that’s callable from anywhere in the program, therefore you don’t have to initialize it as an object. In fact, due to the way it’s made, if you do it’d cause issues with threads, oops!
So then we got to fixing issues. To start, there was a lack of privatization for internal methods and variables – I was able to edit the current running time of the timer from outside by simply calling the variable, it didn’t really like that. After this we did some troubleshooting as the timer broke whenever it was paused and unpaused or simply another timer was started after another ended. This as it happens was actually an issue with overlapping threads. Put simply, if you destroyed and created identical threads too fast then it would stop functioning correctly. The internal methods for pausing actually creates a new timer thread with the remaining time of the first timer whenever you pause and unpause, the same concept applies to when timers ended and started too fast. Fixing this was fortunately fairly simple, if we buffer how fast you can call the method then the JVM has enough time to handle the threads. Unfortunately this does have a worst case scenario of the timer drifting by roughly second over 20 frame perfect pauses and unpauses, but I really don’t think that’ll be an issue in practice.
Update:
After having another look at the code while creating JUnit tests, I managed to crack some of the final bugs and generally cleaned up the code a little. The pause drift has been reduced to 5ms, which is already within margin for error with normal operation, yay!
GitLab move:
This is fairly self explanatory. Draft-docs contains items to be distributed appropriately into docs and dev. As for me, I moved my JSON research and the timers into dev, and then updated the timers to the version 2 that came as a result of mine and Edd’s work.
Later on Thomas was having issues with the GitLab IDE, as it wasn’t allowing him to delete redundant directories without creating a separate branch. I was able to help by just using the cli, this basically didn’t take any time at all really.
Example of JUnit with timers:
After my initial research of JUnit, I’ve implemented some basic functionality tests to ensure that the timers are working. These tests can also serve as a useful example for the other developers in the group to create their own tests for their own modules going forward!