The current report for my CCS Proposal is delayed by a half a month, since in the 1st half of April I had to be dealing with water damage in my rental apartment, that is luckily on sale already. At the same time, whenever I had time for this, I was working on strategies of conservation of my laptop's battery power, ultimately making the strategies generic enough to be able to both: enable me working outside of my office (like I've been doing in the last 2 weeks), as well as reuse most of this research time & code for the “SolOptXMR` project.
However, since this preparation time cannot be attributed directly to my Monero maintenance CCS Proposal itself, I decided not to charge anything for the 1st half of April, report with a delay, and expect the payment with an equal delay – after the 1st half of May and consequently after the 1st half of June, as far as the next payment is concerned.
Summary of my April-May work period
We finally have some new Devs on board. Welcome! As you can imagine, it takes time for each other to learn the work culture, like it took me when I on-boarded and The Old Cr3w was patiently pointing me to the right direction, spending their time on this act.
It is time for me to contribute the same way as they did. Therefore I wanted to primarily spend time on reviewing PRs of the new Devs and explaining nuisances. There was an unfortunate "special" PR, where me and other reviewers had to spend an extra couple of hours, due to a common misunderstanding of how quick some things typically break 🙂 Very briefly: I proposed to split a very large PR into many smaller PRs, which might get reviewed and merged independently, rather than agglomerating them into one big PR, thus risking of not being able to merge neither of the parts in case of a possible merge conflict, as in this version it's all or nothing. As soon as I said it and my idea was rejected, the potential issue that I had predicted has occurred… trice! Please have a read of the PR, if you like. Ultimately the PR went through though.
Here's the full list of the PRs reviewed by me:
Merged or closed:
I was asked by selsta to review specific PRs of GUI. Selsta knows my skill set and this way we can push the most important things very quickly. Of course this doesn't mean, that we pat each other's backs, but rather check each other's work like reviewers are supposed to. It's still fun though for me and a tangible output for you.
Below is the full list of the GUI PRs:
I also took part in the verification of the latest release. Whenever I do it, I always find something to fix in this verification process. This time wasn't any different. I proposed a solution against stale files, which after being reviewed by u/hyc, lead to a much easier and less obtrusive one . These 2 solutions in general conform to the Principle of least astonishment , from the User's perspective. In this case: If I command the environment to be set up, then I want it the be clean of stale files, that were otherwise blocking build process, rather than having to delete the entire work directory by hand first.
Large ongoing tasks
Morero Core – libwallet tests
Here again, selsta asked me to take over this large task of fixing the now outdated `libwallet_api_tests`. As soon as I took a closer look, it turned out, that even the preparation scripts of this test were outdated. I followed the documentation in an external project and found there yet another potential to fix – the daemon was continuously banning the test, as if it was an impostor, so it couldn't even execute properly.
Although the scripts are already published, but not yet merged, the task of fixing the tests themselves (in C++) is in an on-going state.
Monero Research Lab
Rucknium, J-Bermann and me are breaking down the decoy algorithm in order to better understand its flow by performing statistical tests on it. For this, we need to have an alternative implementation. Python was chosen to be the language, which offers a large variety of frameworks and is widely used among Researchers. My take is being documented here.
Simulation of the fee increases
I signed up for simulating the dynamics between the transactions' fee increases and the blockchain’s size increases. I gathered very valuable feedback from AticMine and Endor and am armed to start the simulation. However with the other 2 ongoing tasks (libwallet tests and decoy algo), I'm currently slightly overwhelmed and would like to finalize at least one of them first, before even starting this one.
I opened a few minor branches as well, that I'll just quickly mention here:
As you may imagine, the 3 last PRs are dealing with the preparation of the VSCodium documentation, that I will write, once all such prerequisites are fulfilled.
Long compilation times (RANT!)
I have to allow myself for a bit of rant here. The decoy algo's reimplementation task takes a long time to complete, even though it's not a large one. I'm being slowed down here due to the time that it takes to compile the wallet2 class, or rather its header file, which is anything but an interface. It's rather a source blob with over 2400 lines. I tried to fix this issue way ahead of time, because I knew it would bit me (and others) sooner or later, so I pro-actively opened this PR , but as usual it was not accepted, since this is a change, that speeds up everybody's work, but "doesn't fix any real problems". In the meantime the PR got outdated and I'd have to spend equal span of time to bring it back to life. There's a great article by u/aFungible describing this phenomenon of hesitancy/procrastination of clean work from a broader perspective:
On the webpage you'll see, that wallet2 is topping not only on the detailed compilation time statistics, but on the memory consumption as well, let alone the relative header size. Now I realize, that cleaning up is less important than privacy and other higher values, but you see, here I can't improve your privacy fast enough, because I'm drowning in the mess, that I'm still not allowed to clean up, even though I know how to do it. I try to beg other Devs to review my code but they just won't do it, period. There's not much more that I can do about it, other than asking you, the Sponsors, for a leap of patience.
I personally must admit, that the sluggish reactions of wallet2 affect my mental state negatively by a lot. Working on something, that builds and runs as fast as my own project, the SolOptXMR keeps me from burning out as a Monero Dev.
So here come the good news finally: we are nearing a `Minimum Viable Product` state. In order not to make this post too long, I will publish a separate entry once the MVP is reached. For now I will only tell, that you may already receive hints from our system as to when to switch on/off which mining machine and perform a simulation of the battery state, that includes weather prediction up to 7 days from the current time. Below is an example of a run of the solver, being able to find a time-dependent mining solution, that prevents both battery overvoltage, as well as (and most importantly) undervoltage:
A quickstart guide is available here.
I’m publishing this report 4 days ahead of time, since nothing will change here much more: I will now want to focus on the mentioned hardest and long term tasks, that are already opened and I have an ambition to finalize them before my next month ends, and so will this particular CCS Proposal. Thanks for reading!