Me: maybe I should finally learn plain old C. What could be a good project? maybe a postscript interpreter? Downloading the spec: 912 pages ... maybe not
Moritz Hamann
@moritzhamann.com
Engineering Manager at Bloomberg LP. Opinions are my own. Mastodon: @MoritzHamann@mastodon.social https://moritzhamann.com
On fire today: created my own homebrew tap so I can install tools easier 🤘
blogged (mostly as a reminder to myself) moritzhamann.com/blog/2026-07...
Fixing miss-aligned monospace text in Android browsers
How to make sure your ASCII diagrams are rendered nicely on Android devices
moritzhamann.com
Moritz Hamann@moritzhamann.com · last wk.All the LLMs in the world, and I'm still somehow unable to have a proper monospaced aligned diagram on Android in the web browser ...
All the LLMs in the world, and I'm still somehow unable to have a proper monospaced aligned diagram on Android in the web browser ...
Got nerd snipped into Installing OxCaml but already having issues with incompatibilities ...
New blog post: a new EDIT tool for LLM agents: antirez.com/news/166
A new EDIT tool for LLM agents - <antirez>
antirez.com
got an iPhone for the first time. Current progress: WhatsApp unable to move chat history in 2026 (WeChat had 0 problems). Only option: "Move to iOS" Android app. Except this app only works when the iPhone is still in factory reset mode (obviously don't tell you that before hand)
@sabine.sh proposal to extend the OCaml feed to "Oxcaml" and "O(x)caml" keywords 🤘
Getting a bit into Rust again and have to say that ChatGPT is great to figure out all the little syntax variations that can be useful from time to time, e.g. `match` vs `if let` vs `let ... else`
ECMAScript EXTRA-SPECIAL excitement 😉 🚨🚨🚨 IT'S ABOUT TIME! 🚨🚨🚨 Congrats to @ptomato.name on advancing Temporal to Stage 4 at @tc39.es today 🎉 Temporal is the replacement for the JavaScript Date API 👍
Jason Williams@jason-williams.co.uk · 5mo agoTemporal is now Stage 4 at TC39 🎂🎂🎂 Thanks to all the other champions of JavaScript's new date-time API. It has been a wild ride over many years! I wrote a blog post explaining how we got here 📜 bloomberg.github.io/js-blog/post...
![Code example showing the usage of Temporal.ZoneddateTime
```js
// London DST starts: 2026-03-29 01:00 -> 02:00
const zdt = Temporal.ZonedDateTime.from(
"2026-03-29T00:30:00+00:00[Europe/London]",
);
console.log(zdt.toString());
// → "2026-03-29T00:30:00+00:00[Europe/London]"
const plus1h = zdt.add({ hours: 1 });
console.log(plus1h.toString());
// "2026-03-29T02:30:00+01:00[Europe/London]" (01:30 doesn't exist)
```](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:r5emt2gkdrkb2yc6y7xndxpe/bafkreicgonzisednk3qegophndqf6fnslwtvbd7gshsgtv6fpi3arh2dsi)
I do like the tooling, the backwards compatibility and ecosystem of go, but some of those decisions in the stdlib are really ... interesting. `http.handle("/", handler)` will match every single ULR, `http.handle("/{$}", handler)` only "/"...
OxCaml isn't just useful due to its language extensions; it's making us think through how to engineer OCaml code to be lower allocation by default even before switching. See Mark's progress on an MP3 decoder to speed it up 10x https://www.tunbury.org/2026/02/11/ocaml-mp3/
Optimizing an MP3 Codec with OCaml/OxCaml
After reading Anil’s post about his zero-allocation HTTP parser httpz, I decided to apply some OxCaml optimisation techniques to my pure OCaml MP3 encoder/decoder. The OCaml-based MP3 encoder/decoder has been the most ambitious project I’ve tried in Opus 4.5. It was a struggle to get it over the line, and I even needed to read large chunks of the ISO standard and get to grips with some of the maths and help the AI troubleshoot. # Profiling an OCaml MP3 Decoder with Landmarks Before dividing into OxCaml, I wanted to get a feel for the current performance and also to make obvious non-OxCaml performance improvements; otherwise, I would be comparing an optimised OxCaml version with an underperforming OCaml version. It was 40 times slower than `ffmpeg`: 29.5 seconds to decode a 3-minute file versus 0.74 seconds. I used the landmarks profiling library to identify and fix the bottlenecks, bringing decode time down to 3.5 seconds (a 8x speedup). ## Setting Up Landmarks Landmarks is an OCaml profiling library that instruments functions and reports cycle counts. It was easy to add to the project (*) with a simple edit of the `dune` file: (libraries ... landmarks) (preprocess (pps landmarks-ppx --auto)) The `--auto` flag automatically instruments every top-level function — no manual annotation needed. Running the decoder with `OCAML_LANDMARKS=on` prints a call tree with cycle counts and percentages. > (*) It needed OCaml 5.3.0 for `landmarks-ppx` compatibility; it wouldn’t install on OCaml 5.4.0 due to a ppxlib version constraint. ## Issues 78% of the time was spent in the Huffman decoding, specifically `decode_pair`. The implementation read one bit at a time, then scanned the table for a matching Huffman code. I initially tried a Hashtbl, which was much better than the scan before deciding to use array lookup instead. The bitstream operations still accounted for much of the time, but these could be optimised with appropriate `Bytes.get_...` calls, as the most frequent path is reading 32 bits in big endian layout. The profile now showed `find_sfb_long` consuming 3.4 billion cycles inside requantization. This function does a linear search through scalefactor band boundaries for every one of the 576 frequency lines, every granule, every frame. Switching to precomputed 576-entry arrays mapping each frequency line directly to its scalefactor band index. There were some additional tweaks, such as adding more precomputed lookup tables stored in `floatarray`, using `[@inline]` and `unsafe_get`, `land` instead of `mod`. After this, no single function dominated the profile, and I could move on to OxCaml. # OxCaml OxCaml has `float#`, an unboxed float type that lives in registers, and `let mutable` for stack-allocated mutable variables. Together, they let you write inner loops where the accumulator never touches the heap: module F = Stdlib_upstream_compatible.Float_u let[@inline] imdct_long input = for i = 0 to 35 do let mutable sum : float# = F.of_float 0.0 in for k = 0 to 17 do let cos_val = F.of_float (Float.Array.unsafe_get cos_table (i * 18 + k)) in let inp_val = F.of_float (Array.unsafe_get input k) in sum <- F.add sum (F.mul inp_val cos_val) done; Array.unsafe_set output i (F.to_float sum) done These kinds of optimisations got me from 2.35s down to 2.01s. What I felt was missing was an accessor function which returned an unboxed float from a floatarray, so I wouldn’t need to unbox with `F.of_float`. However, I couldn’t find it. The httpz parser really benefited from OxCaml’s unboxed types because its hot path operates on small unboxed records that stay entirely in registers: #{ off: int16#; len: int16# } # Results The optimisations brought a 29.5s MP3 decoder down to 2.01s. Mostly through standard OCaml optimisations, but OxCaml’s `float#` saved another ~14%. Decoder | Time | vs ffmpeg ---|---|--- ffmpeg | 0.74s | 1x LAME | 0.81s | 1.1x ocaml-mp3 (original) | 29.5s | 40x ocaml-mp3 (Hashtbl) | 6.4s | 8.6x ocaml-mp3 (flat + fast bitstream) | 3.5s | 4.7x ocaml-mp3 (best) | 2.4s | 3.2x ocaml-mp3 (OxCaml) | 2.0s | 2.7x
tunbury.org
Finally got the time to play around with Apple's local LLMs (Foundation Models). So far it's a mixed bag: It's able to answer questions about articles but needs precise prompting and the context window is only ~4.1k tokens, so not much will fit.
installed D on MacOS and got an immediate segmentation fault when running dmd 🫠
just tried gemini to vibe some zig, but the recent redesigns around io interfaces and the frequent changes in the stdlib due to being < 1.0, made this a rather frustrating experience. On the other hand it's a good way to actually learn zig by fixing all the compilation errors ...
I have had enough of Telegram services run by unknown individuals to do the audio transcription task in my Telegram channels. Wrote one using my botlib, ffmpeg and whispher.cpp. May be useful for you as well, perhaps? github.com/antirez/whis... Transcription quality is WAY better.
GitHub - antirez/whisperbot: Telegram bot that transcribes audio messages via whisper.cpp
Telegram bot that transcribes audio messages via whisper.cpp - antirez/whisperbot
github.com
I love how LLMs make it so easy to customise my neovim now. Tiny little scripts that either replace existing plugins or add very specialised workflow enhancements. Just wrote a 100 line function that adds a zen mode with backdrop. Still had to tweak the result, but 95% was basically there
I have included the most relevant section in the alt text of this image of him giving the talk:
![They need to negotiate with each other. They have to probe each other. They have to dynamically figure out a common language so they can exchange information and fulfill the goals that the human programmer gave to them. So that’s why this goal-directed stuff is going to be so important when we have this internet—is because you can’t write a procedure because we won’t know the procedures for talking to these remote programs. These programs themselves have to figure out procedures for talking to each other and fulfill higher-level goals. So if we have this worldwide network, I think that this is the only model that’s going to scale. What won’t work, what would be a total disaster, is—I’m going to make up a term here, API [Application Programming Interface]—this notion that you have a human programmer that writes against a fixed interface that’s exposed by some remote program. First of all, this requires the programs to already know about each other, right? And when you’re writing this program in this one’s language, now they’re tied together so the first program can’t go out and hunt and find other programs that implement the same service. They’re tied together. If this one’s language changes, it breaks this one. It’s really brutal, it doesn’t scale. And, worst of all, you have—it’s basically the machine code problem. You have a human doing low-level details that should be taken care of by the machine. So I’m pretty confident this is never going to happen. We’re not going to have API’s in the future. What we are going to have are programs that know how to figure out how to talk to each other, and that’s going to require programming in goals.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:qfrekkhphlonkdee4pgjba7s/bafkreib576dl43fqp2wjsifodc7xal56g4uyshs34grlcid47xgdszwjou)
Everybody thinks 'https://' stands for 'hypertext transfer protocol secure' but it actually stands for 'head to this place, sucka' followed by a colon and two laser sounds
Doing a lot of renovation work at home recently and www.bbc.co.uk/sounds/brand... is great to listen to while painting rooms
BBC Sounds - Sherlock Holmes Short Stories - Available Episodes
Listen to the latest episodes of Sherlock Holmes Short Stories on BBC Sounds.
bbc.co.uk
> But the rise of Claude Code changed this. For some reason, Claude Code's CLI produces a lot of multi-codepoint grapheme outputs which force Ghostty to regularly use non-standard pages. Too many emojis 😅 mitchellh.com/writing/ghos...
Finding and Fixing Ghostty's Largest Memory Leak
mitchellh.com
so TIL that there is still telegrams in use en.wikipedia.org/wiki/Worldwi...
Worldwide use of telegrams by country - Wikipedia
en.wikipedia.org
Hey #fsharp, what we do with #FsAdvent this year? sergeytihon.com/fsadvent/ Do we have 24 F#ers ready to participate?
Same here. From time to time I look at it, like the premise, try to start using it and stop after a few hours 😔
Kelsey Hightower@kelseyhightower.com · 11mo agoI want to like the Swift programming language. I just c@n't do it.
When you use coding agents for something that produces the bulk of the code of an application that will be used for years, also factor in the technical debt that you are happily accumulating. When you use LLMs an an aid, you could, on the contrary, improve your coding culture.