Posts by pervognsen@mastodon.social
 (DIR) Post #B2wn8yDGqpjheT4h9s by pervognsen@mastodon.social
       2026-02-03T12:20:02Z
       
       0 likes, 0 repeats
       
       A pseudo-etymology of "jettison" that claims it only applies to throwing things out of a jet-powered vehicle would be funny and not too improbable given that they apparently have the same etymological root (jeter, to throw).
       
 (DIR) Post #B2wn8zNEXHIdFekAKG by pervognsen@mastodon.social
       2026-02-03T12:26:42Z
       
       0 likes, 0 repeats
       
       Random factoid, but I'm 100% certain I first learned the word "jettison" when playing Star Trek: The Next Generation - A Final Unity, a point-and-click adventure game that few people played and no-one remembers: https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation_%E2%80%93_A_Final_Unity. It was such a quaint word that it always stuck with me.
       
 (DIR) Post #B2xfSSj71P0PJZiCH2 by pervognsen@mastodon.social
       2026-02-03T23:54:32Z
       
       0 likes, 0 repeats
       
       Maybe I'm too harsh but this is like nails on chalkboard: https://ratatui.rs/tutorials/json-editor/app/#the-full-application-state. Since it's a beginner tutorial maybe it's driven by the (IMHO misguided) notion that beginners would be confused by using enum fields properly to make invalid states unrepresentable.
       
 (DIR) Post #B2xfSTqar4aGn4DgZc by pervognsen@mastodon.social
       2026-02-04T00:12:46Z
       
       0 likes, 0 repeats
       
       Although it's a ready-made homework exercise you can give to students telling them to refactor the example so the state machine is properly represented with no fake degrees of freedom.
       
 (DIR) Post #B2zN4SIFZTLyA7TD04 by pervognsen@mastodon.social
       2026-02-04T14:32:41Z
       
       0 likes, 0 repeats
       
       The more I use them, the more I'm convinced that, for most code with non-trivial case analysis, let-variables with exactly-once definite assignment analysis are usually ergonomically superior to the expression-oriented value yielding typical of functional languages. It's especially true as soon as you find yourself tupling things just for the sake of yielding multiple values in an expression-oriented way, which I always found awful.
       
 (DIR) Post #B2zN4TjEEeWmc56Ggq by pervognsen@mastodon.social
       2026-02-04T15:03:13Z
       
       0 likes, 0 repeats
       
       Also, with every code editor nowadays having one-button Find References, you can find all the let assignments on different control flow paths when hovering the cursor over a given local variable name. Names are nice for connecting producers and consumers.If your language has complete type inference there's also no difference with respect to let variable assignments vs expression-oriented code. Rust has incomplete type inference so some code patterns won't preserve inferability, but most will.
       
 (DIR) Post #B2zN4UxRfHUgQSl8UK by pervognsen@mastodon.social
       2026-02-04T15:18:34Z
       
       0 likes, 0 repeats
       
       You can write eitherlet (min, max) = if x <= y { (x, y) } else { (y, x) };orlet min;let max;if x <= y {    min = x;    max = y;} else {    min = y;    max = x;}orlet min;let max;if x <= y {    (min, max) = (x, y);} else {    (min, max) = (y, x);}and it will infer equally. That example isn't compelling for the assignment-based alternatives (I'd use the expression-oriented one-liner) but it makes a big difference when the case analysis and nesting gets more complex.
       
 (DIR) Post #B2zN4VzFq2XFcMc5wm by pervognsen@mastodon.social
       2026-02-04T15:22:40Z
       
       0 likes, 0 repeats
       
       For that matter, I just noticed you can replacelet min;let max;withlet (min, max);which I hadn't tried before (of course it's common to do that when you have an initializer on the right-hand side of the let). Since it also works with let [min, max]; I guess any well-formed irrefutable pattern works without a let initializer, which is a bit funny-looking but I guess makes sense.
       
 (DIR) Post #B31FOVayaqFssUCTFg by pervognsen@mastodon.social
       2026-02-05T10:14:04Z
       
       0 likes, 0 repeats
       
       Weird FUD by Phoronix about LTO builds since Mesa is apparently turning off their LTO builds due to "impossible to reproduce bugs that only happen in LTO builds". I'd like to get other people's take, but I'm assuming what's actually happening is that like with -O1 vs -O3, optimizing across translation units is exposing latent UB bugs (or much less likely, latent compiler bugs not directly related to LTO), and it's not that the LTO pass itself is buggy.
       
 (DIR) Post #B31FOb1kOjdlixlQAq by pervognsen@mastodon.social
       2026-02-05T10:15:23Z
       
       0 likes, 0 repeats
       
       Incidentally, this has always been one of the socio-technical problems I've had with LTO in large C and C++ code bases. All the scariest bugs in code bases for those languages are UB-related and might only show up at higher optimization levels. And because of slow build times, most devs understandably don't want to do all their local rebuilds at -O3, never mind -O3 plus LTO (even thin LTO), so you're not actually iterating and dogfooding the thing you're shipping if you ship LTO.
       
 (DIR) Post #B31FOb2oKmUVmGGGpc by pervognsen@mastodon.social
       2026-02-05T12:11:40Z
       
       0 likes, 0 repeats
       
       With the right adjustment in your mindset, any time you find that a bug with your code only materializes with different compilers or compiler versions or optimization flags, you're given a gift that lets you root out UB bugs in your code. Or, much more rarely, you get to root out compiler bugs, which is less fun. But having been in the situation of trying to ship things with latent UB like this, I understand the frustration. So don't ship LTO for now, but you (probably) still have serious bugs.
       
 (DIR) Post #B31FOfdpF6Ta2Dbt56 by pervognsen@mastodon.social
       2026-02-05T12:16:23Z
       
       0 likes, 0 repeats
       
       If you're a real psychopath you can try to fuzz your code for UB by compiling and auto-testing it with many different permutations of compilers and compiler configurations like that.
       
 (DIR) Post #B32bFvypWCNqFgdMm0 by pervognsen@mastodon.social
       2026-02-06T06:51:40Z
       
       0 likes, 0 repeats
       
       This seems mildly terrifying if you're using AMD's auto-update tool on Windows on an untrusted network: https://mrbruh.com/amd/. Them immediately closing it as a "won't fix" because it involves a MITM attack is odd. I guess that policy must have been more concerned with CPU-level vulnerabilities?
       
 (DIR) Post #B32bG1Du1aPYVsiySe by pervognsen@mastodon.social
       2026-02-06T06:55:25Z
       
       0 likes, 0 repeats
       
       Like, I don't know how many regular users have that pre-installed by whoever sold them their computer, but it must be a lot of people. It's a race to see if your computer gets remotely pwned first by ASUS's or AMD's auto-updater if you all have that pre-installed crapware.
       
 (DIR) Post #B34TrVsIcBxUyUuJ4S by pervognsen@mastodon.social
       2026-02-07T03:21:12Z
       
       0 likes, 0 repeats
       
       There's long-running debate in programming about brevity vs descriptiveness for names, but something I don't see pointed out is that strong conventions (either universally or in your code base) like 'ptr' for memory pointer and 'idx' for sequence index are _more_ descriptive than 'pointer' and 'index'. A 'pointer' could be a mouse pointer and an 'index' could be a database index.
       
 (DIR) Post #B36fhNCbakZ6wpFxVQ by pervognsen@mastodon.social
       2026-02-08T03:54:42Z
       
       0 likes, 0 repeats
       
       There's a funny thing about sampling profilers for games: at typical default sampling rates you're getting so few samples in a particular frame that only the subsystem-level parts of the stack near the main loop are statistically meaningful and almost everything else is noise. But with a stack snapshot you're capturing the noisiest parts of the call stack first. In the worst case (e.g. 64-depth truncated snapshot of a deep call stack) you might not even capture any stable parts of the stack.
       
 (DIR) Post #B36fhOXub1Cd7CEUM4 by pervognsen@mastodon.social
       2026-02-08T04:03:25Z
       
       0 likes, 0 repeats
       
       The low sampling rate on a per frame basis is something that most people point out but I haven't seen many people focus on the fact that you're literally prioritizing the statistically noisiest part of the stack. Which can be very useful to catch big hitches in unexpected places near the leaves, but most of the non-stationary data there is literal noise. Obviously cranking the sampling rate helps a lot (albeit with trade-offs).
       
 (DIR) Post #B36fhRk4iFiN1mwkEK by pervognsen@mastodon.social
       2026-02-08T03:56:56Z
       
       0 likes, 0 repeats
       
       So ironically the only statistically relevant parts of the data tend to be the subsystem-level durations of the frame and those can be trivially marked up with instrumentation by hand since there's so few of them (which also has essentially zero overhead and perturbative probe effect). Of course there's proper effective ways to use sampling profilers for applications like games and e.g. Superluminal (and Tracy if you set it up for your app) makes it easy.
       
 (DIR) Post #B3FEuIv9s94d5tg0FU by pervognsen@mastodon.social
       2026-02-12T02:45:45Z
       
       0 likes, 0 repeats
       
       Remember when "top posting" was the ultimate online faux pax? I was just thinking that pretty much all the ways of interacting on social media nowadays are the equivalent of top posting.
       
 (DIR) Post #B3I3S1XUO66h3VnVeC by pervognsen@mastodon.social
       2026-02-12T23:22:20Z
       
       0 likes, 1 repeats
       
       The Midlayer Mistake: https://lwn.net/Articles/336262/