H. Mijail's Blog

Warum? Ach, darum! My team at Consensys R&D worked mostly with Dafny , the verification-friendly language. We enjoyed good success with it in our projects during the last few years; our extensive use got us a mention in Rustan Leino's Program Proofs book, and we even got a Best Paper Award in the 2022 edition of the International Conference on Formal Methods for Industrial Critical Systems! Unfortunately, our team at Consensys is no more. So I finished my tool DARUM for a v1.0 release, and this post aims to gather the lose threads and offer an easier entry point for external users.

Back in 2017 I had a kinda esoteric question about Ethernet NICs with less-than-frame latency, based on my experience with networking software and hardware, and the evidence for something "atypical" being in use by High Frequency Traders. So I posted my question to Stack Overflow. The question got a lot of pushback, which I found bizarre. It had to be moved across 3 SO sites... and finally it stayed in SO proper, where anyway the only response I got was my own, when some days later I found the necessary information myself. Aaand a couple of years of inactivity later, the question just got deleted. 🤷‍♂️ I thought it was an interesting question (why would I ask it otherwise); it was an interesting collection of pushback; and had an interesting answer. So I saved them and here they are for posterity.

This is about a shocking realization I got while learning about the LMAX Disruptor – a data structure / architecture that got published in 2011 and made some waves across the web because it allowed LMAX to process +6M transactions per second on a single thread. In Java. Which was interesting because Java was (still?) supposed to be too slow for that kind of thing. By then I was already a couple of years out of the Java world and getting into embedded C, so I took a mental note to look into it just out of curiosity. But, as could be expected, the note was promptly forgotten. I'm now looking again into Java, so finally I managed to take a peek at the Disruptor. Shock: this is just a description of what I was implementing in C while I was still learning it! But it's not that I'm a genius; it's that this is probably the only way to do things when in a limited environment. In fact, the basic architecture is the one used typically in drivers and in Linux's NAPI networ...

If your local feature branch tracks origin/feature , you are probably working extra, no matter your flow . There are lots of places online where one can learn about GitFlow, but it's seemingly always discussed in a local way; the details, subtle or not, about using GitFlow when you are pushing and pulling your changes through the network are never mentioned. Now, GitFlow is a bit long on the teeth, and some of the younger and simpler alternatives do take into consideration things as Pull (or Merge) Requests; lately some even want the original GitFlow to be considered harmful . But still, there's a common basic concept in GitFlow and the alternatives, which is local feature branches. How and when exactly to merge them back into a development branch is one of the big differences, but is rarely detailed. The goal of this post is to gather some tips on how to keep developing in the local feature branch while staying involved on a lively repository; and how to make easier t...

Every C programmer knows to use #defines and #ifdefs to disable compilation for a piece of code. But not everyone knows that there are better ways; the problem with this strategy is that the code becomes invisible to the compiler (and "smart" indexers), which means that it stops being checked for correctness. Also, if the rest of the code changes substantially, like variable renaming, function changing their signatures, etc, the disabled part falls out of sync and will need possibly serious work when re-enabled. There are easy improvements to the #ifdef strategy, with the inconvenience that they add boilerplate and/or waste cycles on runtime (important on embedded environments). But there's also a way to remove both the boilerplate AND the runtime checks!

TL; DR: as of last update for OS X 10.11 / Instruments.app 7.1, you can't really create meaningful CPI Flame Graphs on OS X because of bugs in Apple's tools, both GUI and command-line. There are some alternatives and workarounds; for an alternative to a CPI Flame Graph, Instruments.app might be good enough. I sent 6 bug reports to Apple, and 5 of them got marked as duplicates; so maybe some Instruments post-7.1 will get good enough to allow the data extraction needed for real Flame Graphs. I have been trying to generate Brendan Gregg's Cycles-Per-Instruction Flame Graphs  on OS X (10.10), mostly to check cache-related CPU stalls. However, after working on it for a good while, it's looking to me like the given method is somewhat shaky, and the same or better insights about the code can be gotten more easily; partly thanks to Instruments.app,  … a nd partly in spite of Instruments.app.

This is not really a tutorial on makefiles; there are lots of those around the web. But most of those are very outdated, and/or follow dubious practices. You'll end up with a makefile which was OK for a make and a compiler from the 90's, maybe even around year 2000. Even the GNU make manual recommends unnecessarily complicated things, given the capabilities gcc has grown in the last decade . So, if you know how makefiles generally work (it's enough to know what a rule, a recipe and a variable is), and want to improve yours or know of better options, the following may help.

In the 60's, Freed Brooks led the development of the IBM/360 system and its OS. The experience made him write the famous The Mythical Man-Month. Turns out that Dijkstra also wrote about that system in his EWD255. And everything he complained about on that system is the standard nowadays! Sounds like he considered that a lot of the complexity that should be fixed by the computer is being dumped on the programmer; that the features touted by the IBM/360’s OS are in fact partial fixes to the bad design of the computer:

Well, that took some time. Quite an exacting process… which makes you get a new perspective of how Linux is made, and what it takes to keep loose collaboration at a high quality level. And interesting too how such a simple patch evolved. First it made me think of the bike shed …

Finally I managed to get a mental model of git that allows me to do everything without needing to google around. And this is a quick memory dump. There are other git cheatsheets, but this is mine.

Por fin conseguí hacerme un modelo mental de git que me permite hacer de todo sin necesidad de google ni esquemas ni Stack Overflow ;P. Y ésta es mi chuleta / "volcado de memoria". Parece que no hay muchas cosas así en español; a ver si le sirve a alguien. La idea era mantenerlo muy corto y al grano — como una chuleta, vaya. Asumo que sabes de qué va en general git y qué son cosas como un puntero y una lista simplemente enlazada. Si hay interés lo expandiré en algo más "tutorial".

Well, it happened. When applying for a job, I got sent to a Codility test. And even though I already had some good practice with them, I managed to do badly in stupid ways – ways that 2 years ago I had already identified and even taken notes on. Just, in the heat of the moment I forgot about those rules of thumb. And in fact I think these hints should be given by Codility themselves – because otherwise you are practically ambushed, even more so if you didn't take the time to thoroughly explore how they work. So here are my hints-to-self, now for everyone. The summary is: don't think of Codility as a coding interview; this is primarily about getting something (anything!) working, ASAP.

Gitk (as of git 2.4.2) has its bottom left and right panes the other way round to what I like: the bottom right shows the file tree or the patch summary, while the bottom left shows the contents of what is selected on the right. Isn't that kinda non-standard? There is no official way to swap those panes, so here's a little hacky patch to do it.

… or, "using quotes by well-known people to put forward possibly unpopular points" ;P Sometimes I have a fully formed opinion to write about; lots of times I don't, but I have an intuition of where I want to go. And those times seeing what some of the "greats" in the field think can be a bit of a beacon.

It's been kinda hard to get Eclipse to work well with big CDT projects (say, the Linux kernel, or even a BuildRoot project including the Linux kernel). The documentation for Eclipse is between non-existent and unhelpful, and I only could find a post that talked specifically about preparing an Eclipse project for the Linux kernel . But that post explains nothing, and does some arbitrary things. So this is the generalization of that.

Couldn't find anything concise, so here's my solution: a sweet short Expect (the CLI variety installed by default in Ubuntu) script to open a telnet session, feed in the user and password, AND continue to an interactive session .

Imagine that you have a struct s which sometimes needs to be volatile (because it maps to a set of hardware registers) but other times you'd rather have it non-volatile (because you are working on a bunch of such structs that have been stored, so they are no longer used to interface to the hardware and you could do without the performance penalty of volatile). That is easy enough: you can have your variables declared volatile or not depending on the situation. But what happens when you have a function to deal with those structs? Could it be implemented so it not only works, but does the right thing in both volatile and non-volatile structs? The trivial way to have such a thing is by just defining 2 versions of the function (with different names of course) with the differently qualified parameters; but another possibility is to define a union type in which one member is the plain type and the other is the volatile-qualified type, and make the function parameters use that...

I have found what looks like a hardware bug in the AT90CAN128! I guess I could be happy in a geeky way, but the number of hours spent trying to track the problem make it a bit difficult :P. The thing is that aborting a pending MOb in the CAN controller embedded in the AT90CAN128 can leave CONMOB in an unexpected state. I am not totally sure if this is a hardware bug… or could be Atmel's library at90CANlib_3_2 being buggy AND misleading.

Atmel Studio 6, which is (ununderstandably!*) based on Visual Studio (2010?), suddenly stopped showing anything in the Solution Explorer pane. The pane was there, it just remained empty, blank, apart from the "Properties" button (and the "Show all files" button shows up too, depending on the frontmost pane).

Long story short: Atmel Studio's inflexibility forces quite a strict isolation, which forces you towards the purist side (potential advantage) and makes compile-time library configuration very difficult (clear actual disadvantage). So it's not a very clear win - though I am rather liking it.