Programming Leftovers
-
Software testing, and why I'm unhappy about it
Automated testing of software is great. Unfortunately, what's commonly considered best practice for how to integrate testing into the development flow is a bad fit for a lot of software. You know what I mean: You submit a pull request, some automated testing process is kicked off in the background, and some time later you get back a result that's either Green (all tests passed) or Red (at least one test failed). Don't submit the PR if the tests are red. Sounds good, doesn't quite work.
There is Software Under Test (SUT), the software whose development is the goal of what you're doing, and there's the Test Bench (TB): the tests themselves, but also additional relevant parts of the environment like perhaps some hardware device that the SUT is run against.
The above development practice works well when the SUT and TB are both defined by the same code repository and are developed together. And admittedly, that is the case for a lot of useful software. But it just so happens that I mostly tend to work on software where the SUT and TB are inherently split. Graphics drivers and shader compilers implement some spec (like Vulkan or Direct3D), and an important part of the TB are a conformance test suite and other tests, the bulk of which are developed separately from the driver itself. Not to mention the GPU itself and other software like the kernel mode driver. The point is, TB development is split from the SUT development and it is infeasible to make changes to them in lockstep.
-
Dirk Eddelbuettel: RApiDatetime 0.0.8 on CRAN: Maintenance
RApiDatetime provides a number of entry points for C-level functions of the R API for Date and Datetime calculations. The functions asPOSIXlt and asPOSIXct convert between long and compact datetime representation, formatPOSIXlt and Rstrptime convert to and from character strings, and POSIXlt2D and D2POSIXlt convert between Date and POSIXlt datetime. Lastly, asDatePOSIXct converts to a date type. All these functions are rather useful, but were not previously exported by R for C-level use by other packages. Which this package aims to change.
-
gui_engine runs in initrd
I posted yesterday about compiling 'dialog' statically, enabling text-mode GUIs in the initrd:
https://bkhome.org/news/202301/first-bootup-2-letter-language-asked-in-initrd.html
'dialog' is completely stand-alone, doesn't require any shared libraries, and is 508KB. It supports unicode characters.
All of the utilities in the initrd are statically-linked; 'busybox' is another example.
[...]
The example is named 'example' and is 304KB. That is a statically-link standalone application. Most of the size is the linked-in libsdl, so adding more features to the app won't increase the size much.
Very limited widgets, no documentation, but very simple and small C code. So definitely interested in taking it on as a project. Might be of interest to someone else also. First task -- there is no way to exit from the example, had to do a hard power-off.
-
What is ActiveRecord becomes from Rails
Have you heard about the ActiveRecord becomes method from Rails? Maybe it’ll come handy one day.
-
How to prevent an infinite loop
-
My podcast tastes | AksDev
I just wanted to write this down since I’ve been talking a bit about podcasts on fediverse.
I listen a lot of podcasts when gaming, it’s kind of a way how I relax. Nothing like good multiplayer FPS where I can turn off my brains, then I can listen podcasts on the side. :)