Programming Leftovers

posted by Roy Schestowitz on Mar 27, 2026

• Jonathan Almeida: Use Android Studio for resolving conflicts in Jujutsu

  You can use JJ's built-in editor for conflict resolutions, but I've found it difficult to follow. A recommendation from co-workers was to use Meld and that has worked quite well once I (begrudingly) accepted that I needed to download another single-purpose app.

• University of Toronto ☛ Considering mmap() verus plain reads for my recent code

  The other day I wrote about a brute force approach to mapping IPv4 /24 subnets to Autonomous System Numbers (ASNs), where I built a big, somewhat sparse file of four-byte records, with the record for each /24 at a fixed byte position determined by its first three octets (so 0.0.0.0/24's ASN, if any, is at byte 0, 0.0.1.0/24 is at byte 4, and so on). My initial approach was to open, lseek(), and read() to access the data; in a comment, Aristotle Pagaltzis wondered if mmap() would perform better. The short answer is that for my specific case I think it would be worse, but the issue is interesting to talk about.

• Matheus Moreira ☛ Generators in lone lisp

  Generators are also known as semicoroutines: specialized coroutines that only ever yield control back to their own callers. Sounds like an oddly academic distinction to make but it's actually a huge simplification that makes them much easier to not only understand but also to implement.

• Daniel Stenberg ☛ Don’t trust, verify

  Software and digital security should rely on verification, rather than trust. I want to strongly encourage more users and consumers of software to verify curl. And ideally require that you could do at least this level of verification of other software components in your dependency chains.

• Henrique Cabral ☛ Two studies in compiler optimisations

  In this post we’ll dive into the implementation of some of the LLVM1 optimisation passes using two simple examples which, nonetheless, will help us pull back the veil on the complexity involved in producing highly-optimised code. We will see how small source changes can trigger different paths in the compiler’s internal processing with unexpected consequences, demonstrating how achieving high performance can be as much an art as it is a science for both compiler developers and users. I have also included a few exercises for those interested in getting their hands dirty, but they are not required to follow along with the main text.

• R / R-Script

  • Rlang ☛ Why Learning R is a Good Career Move in 2026

    Over the course of my career as a Data Scientist, I’ve worked on projects ranging from simple code reviews, to large application builds. For the most part, I have used R to do this.

    If you’re getting into coding or data science, one question you’re probably asking yourself is “Which language should I learn?”

    This blog aims to show you why R might be a good decision.

• Python

  • Kenneth Reitz ☛ A Mini DAW in the Python REPL

    That music theory library I wrote about kept growing. I added playback because I wanted to hear what I was modeling. Then synthesis because I didn't want external dependencies. Then drums, then effects, then automation. Each step was small and made sense at the time.

    And now it's... kind of a DAW? A weird one. A tiny one. But it works, and I keep using it, so here's what happened.

  • Kenneth Reitz ☛ PyTheory Is Awesome

    You give it fret positions. It tells you what chord you're playing. That's it. That's the trick. And it works with any tuning, any number of strings, any instrument you can model as a fretboard.

    I built this library called PyTheory (source), and I think it might be the thing I'm most proud of building. More than Requests. More than anything with millions of downloads and corporate adoption and conference talks. This little music theory library that almost nobody uses, that almost seems purposeless, that I built entirely for myself — it's the one.

  • [Old] N R Posner ☛ When Vectorized Arrays Aren't Enough

    I've been contributing on and off to the McFACTS simulation project for a few months now, and am currently in the process of testing and merging some pretty substantial optimizations to the core 'business logic' of the simulation, which mainly consists of long series of NumPy array operations.

    Pretty much all the optimizations in the pipeline right now are basically identical, to the point that I've considered just writing a macro to write the code for me. I figured it would be worth condensing what I've learned in the last few months about how these optimizations work concretely, as well as the intuition behind them.

    None of this is particularly arcane or hardware specific, and while we will be getting into some x86s assembly at the end, it's mainly illustrative and helpful for validating the intuitions we're building.

    This may be especially valuable if you're an author of scientific Python code, and you're struggling with slow-running programs despite being told in undergrad that NumPy arrays are really fast.

• Java/Golang

  • Kevin McDonald ☛ Faking protobuf data in Go

    If you build Go services that use protobuf over gRPC, you often need realistic-looking data. Sometimes you need a lot of it and your creative juices and manual data entry only goes so far. Tests, local demos, and stubs all benefit from messages that look plausible without carrying meaning.

    FauxRPC addresses this. It’s a small Go library that fills protobuf messages with plausible data. The focus is not perfect realism; it’s speed, convenience, and reducing boilerplate.

    This article covers two main use cases: populating generated protobuf types and working with dynamic descriptors. Along the way, you’ll see how to generate data and control its behavior for repeatable results.

  • Alex Edwards ☛ The 9 Go Test Assertions I Use (And Why)

    A few weeks ago Anton Zhiyanov published the blog post Expressive tests without testify/assert. It's a good and well thought-out post, and I recommend giving it a read if you haven't already. In the post, Anton makes the argument for not using packages like testify/assert for your test assertions, and instead creating your own minimal set of assertion helpers to use in your tests. In fact, so minimal that there are only 3 helpers he uses: AssertEqual, AssertErr and AssertTrue.