The Qemu implementation uses a Flattened Device Tree (FTD) to manage the virtual implementation of the physical devices in a machine. I need to create a FTD entry for the MCTP-PCC implementation I am writing in Qemu. Since this is new to me, and I am working (as I most often do) via Ttrial and error, I want to see the FTD entry after I write it. Here is how I am dumping it.
Continue readingIn my last article on the Long Refactoring series, I elided the process I went through to solve the bug. While preparing to turn the articles into a presentation, I went through the steps myself again, and came across the bug. When I was writing the articles, I was pressed for time, and didn’t go through the process of solving it step by step, which in turn means there is a gap between the pre-and-post states of the code: you can’t get there from here.
Let me take it from where I mentioned that I found a bug, and added the unit test that shows it.
Something I did in a commit broke my code. I have a git bisect that shows me the last good commit and the first bad one.
Continue readingAmpere Computing chips run the ARM64 instruction set. My laptop is a Dell running x86_64. In order to edit locally, but build remotely, I make use of servers in our datacenter. These are the steps I am taking.
Continue readingWhile writing the last article, I noticed that I had made a bunch of little changes to the files without explicitly meaning to. I didn’t include them in the diffs. However, on my screen, I have a bunch of changes that appear to be…not changes:
Continue readingThe typical approach to Data handling is
We want out code to reflect that structure. In doing so, we make it much easier to adapt the code to read from different sources and write to different destinations.
Continue readingThe heart of the code is the call to solve a single puzzle; the function tree_to_solution_string. We want to write a test that runs just this function. Getting there is not so easy.
This method is buried deep within the class SudokuSolver. But creating one of these essentially runs the entire code. In fact, we can redo our original test to run the code as a python call as opposed to a subprocess call. Lets’ start with that.
Continue readingOur test takes 5 seconds to run. That is not horrible, but it does not bode well for when we write more tests. We don’t want to explode that number, and we want to be able to write more focused test. I’m going to do some project setup that will enable us to do more development, including fine grained unit tests.
I’m going to start by using tox.
Continue readingCongratulations, you got your code to run! You are done! Ship it!. Just don’t expect to be able to read it next month. You need to maintain it. You need to add new features. It is a mess.
Give yourself a well deserved break. Then come back to it.
Continue reading