fidzu : software

I wrote a piece over on the Oh Dear blog about a failure mode that most uptime monitoring quietly gets wrong: a domain gets pulled from its registry's zone, but its authoritative nameservers keep answering, and cached resolvers happily serve the stale delegation for days. Your monitoring says green. The domain is gone.

07 Jun 2026 7:01pm GMT

Have you ever written a query where the GROUP BY was easy, but the aggregate was the problem? You know how to group the rows.You know what result you want for each group.But none of the built-in aggregate functions really match your logic. So you end up with a long expression using SUM(), CASE, IF(), […]

07 Jun 2026 7:01pm GMT

For years, prefetching made me uneasy. It can make websites feel faster, but it also asks visitors to spend bandwidth, CPU, memory, and battery on pages they may never open. That always felt a little wasteful, and maybe even a little disrespectful.

That unease also comes from a deeper belief: prefetching should not be a substitute for a fast site. Too many sites are weighed down by unnecessary JavaScript, tracking scripts, third-party widgets, heavy fonts, and oversized assets. Prefetching should not be used to hide that bloat. Before considering prefetching, make your site light and fast.

A couple months ago, while updating my HTTP header analyzer, I added support for the Speculation-Rules HTTP header. Learning about the Speculation Rules API inspired me to try it on my own blog.

The idea is simple: a page can give the browser a small JSON rule set that says which links are safe to prefetch, and when. Those rules can live directly in the HTML using <script type="speculationrules">, or in an external file referenced by the Speculation-Rules HTTP header.

For my blog, I added the rules directly to the HTML of every anonymous page request:

<script type="speculationrules">
{
  "prefetch": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/search*" } }
      ]
    },
    "eagerness": "conservative"
  }]
}
</script>

The rule tells browsers that any same-origin link is safe to prefetch, except for paths under /search*.

The eagerness: conservative setting fires the prefetch on pointerdown or touchstart, meaning the browser only starts prefetching once the user begins to click or tap a link. There are more aggressive options, such as prefetching when a link becomes visible or when a user hovers over it.

Some of you might point out that browsers have supported prefetching for years through the older <link rel="prefetch"> tag. That is true, but I've never loved it.

Traditional prefetching is great when the next page is highly predictable, like the next step in a checkout flow or setup wizard.

On many websites, including my blog, it's anyone's guess what a visitor will click next. Sometimes you can make a smarter guess, but it is still a guess.

And when you guess wrong, visitors spend bandwidth, battery, and compute on pages they never visit. Multiply that across millions of sites and visitors, and those speculative requests add up.

So why implement Speculation Rules? My site was already fast without being static. With eagerness: conservative, the browser waits until the user has already started an action. At that point, the navigation is no longer a vague prediction. It is very likely to happen.

Speculation Rules also respect Battery Saver and Data Saver modes. If a device is low on battery, memory constrained, or trying to conserve data, the prefetching is skipped.

So is prefetching still worth it when the user has already started to click? I think so. With eagerness: conservative, the browser only gets a small head start but something is better than nothing.

Browsers already do some speculative loading on their own without Speculation Rules, but only for high-confidence destinations, like the address bar suggestion you are typing toward.

But they will not prefetch arbitrary links on a page, and for good reason. Prefetching /logout, for example, would sign the visitor out, even if they change their mind and never complete the click or hit Enter.

That is why Speculation Rules can be useful. You can tell the browser which paths are safe and which to leave alone.

In short, Speculation Rules changed my mind because they make prefetching feel more responsible: don't prefetch too much, don't prefetch too early, and only give the browser a safe hint when the user's intent is clear.

07 Jun 2026 7:01pm GMT

A new minor release 0.4.27 of RQuantLib, the first in over a year, arrived on CRAN a couple of minutes ago, has just now been uploaded to Debian, and is being built for r2u as well.

QuantLib is a rather comprehensice free/open-source library for quantitative finance. RQuantLib connects (some parts of) it to the R environment and language, and has been part of CRAN for nearly twenty-three years (!!) as it was one of the first packages I uploaded to CRAN.

This release of RQuantLib brings an update to the interface for all equity options, vanilla and exotics as well as implied volatilities. We now support the option maturity via either an actual maturity date, or the (fractional business-day years) numeric. This uses a clever little Rcpp trick I should discuss in a separate blog post. We also re-ran compileAttributes() to re-create the RcppExports.cpp file now using a slightly improved way of calling Rf_error for an ongoing Rcpp transition, and did some more standard maintenance. The details from the NEWS file follow as usual.

Changes in RQuantLib version 0.4.27 (2026-06-07)

• All equity option functions can now take either a (fractional) time span to expiry or a given date, and accept a daycounter setter.

• Two very old schedule helpers had a superfluous try/catch removed.

• The continuous integration setup received a minor update.

• The RcppExports.cpp file was updated to aid a Rcpp transition.

Courtesy of my CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

07 Jun 2026 2:44pm GMT

I finally carved out some time today to prepare and release debsecan-mcp v0.1.2 to PyPI. During this release, I integrated PyPI's trusted publisher mechanism, which authenticates directly via GitHub Actions and eliminates the need for manual uploads or static API tokens.

07 Jun 2026 12:49pm GMT

A while back, I got my first subwoofer (a surprisingly nice addition to the movie experience, just like rear speakers were). But I live in an apartment, and I don't want to annoy my neighbors at night (the speaker cone points literally down into the floor, and I have no idea how much my neighbors get to share in my enjoyment). So, what to do?

It turns out my receiver supports a sort-of documented serial protocol; it doesn't have an actual serial port, but you can telnet into it (only one session at a time!) and get the same two-way stream. (It also has a HTTP version which I find less useful.) So this allows me to impose my own policy, and of course, doing it via an existing Home Assistant adapter or something was no fun and also thoroughly frustrating, so I saw it as an opportunity to keep maintaining my low-key Rust skills. (No, no LLM code generation. If I'm going to spend time on this, at least I can learn something myself. I think I asked one for code critique at some point, but I can't remember.)

The policy is roughly: If I'm watching TV after 22:00, then the subwoofer is either turned off (if possible) or turned down -12 dB (the maximum). But if I'm watching a Blu-ray or another input like that, that's presumably a conscious tradeoff I've made and things are left at normal. Everything gets a bit more complicated by the fact that the receiver tends to lose state when doing certain switches, and when it boots, it takes a minute or two before Telnet responds, and when it shuts down, it goes into this weird limbo state where it doesn't respond to anything but the TCP connection seems still up.

And then I figured out I also wanted to dim the display when watching movies (again, only certain inputs), but not for a couple of seconds after making any adjustments. And after doing that, I figured that my access point LED should also be turned off, which happens to be some SNMP writable stuff against the Cisco wireless controller it hangs on.

So, if you have a Denon or Marantz AVR, a Cisco access point on a controller, and my exact preferences about what to do about the subwoofer, then you are free to download and use my software to impose that policy. It is "is distributed in the hope that it will be useful", as one says. If you have IPv6.

07 Jun 2026 8:15am GMT

Last year I wrote some Lisp related AI apps. There was a syntax highlighter that used the LLM to determine how to colorize and highlight syntax, and a prompt refiner that takes a wimpy LLM prompt and creates more elaborate prompt from them.

I took the apps down last week. They were `vibe coded' and therefore approximate and had bugs (but that's to be expected), but they had a security hole where you could hijack the LLM processing with your own prompt turning my app into an open relay using my API key. Last week I discovered that my AI spend on video creation was becoming serious. This is odd because I never create AI video. It turned out that my app was being hijacked by a proxy in Luxembourg and was generating videos on my dime.

So I shut down the apps. I knew they had the potential of being abused, and I was willing to tolerate a small amount of abuse, but it didn't occur to me that syntax highlighter could be hijacked to generate gigabytes of video at my expense. Future applications will be careful to obtain the API key from the user.

01 Jun 2026 7:00am GMT

Metaobject Protocol (MOP) Implementation in CLRHack

The Metaobject Protocol in CLRHack is a high-performance implementation of the Common Lisp Object System (CLOS) integrated into the .NET 8.0 Common Language Runtime (CLR). It provides a complete meta-compilation pipeline that bridges the gap between dynamic Lisp semantics and the static CIL (Common Intermediate Language) execution model.

Core Architecture

The MOP is implemented through three primary layers:

1. The Metaobject Hierarchy (C#): A set of foundational classes in LispBase representing classes, methods, generic functions, and slot definitions.
2. The Runtime Engine (MopRuntime): A centralized orchestrator that manages class finalization, method combination, dispatch caching, and instance allocation.
3. The Compiler Bridge (Lisp): Transformations in ast.lisp that translate high-level CLOS forms (defclass, defmethod) into optimized runtime calls.

Instance Representation

Because the CLR type system is strictly single-inheritance and statically defined, CLRHack decouples Lisp-level inheritance from C# inheritance. All CLOS instances are represented by the StandardObjectInstance class, which contains:

• A reference to its ClassMetaobject.
• A private object[] storage array for instance slots, indexed by locations calculated during class finalization.

The Dispatch Pipeline

Generic function invocation is the most complex part of the implementation. When a generic function is called:

1. Cache Lookup: The DiscriminatingFunction first checks a thread-safe dispatchCache using an InvocationCacheKey (a stack-allocated struct) to find a previously computed effective method.
2. Applicability & Precedence: If the cache misses, the runtime computes all applicable methods and sorts them based on specializer specificity and the Class Precedence List (CPL).
3. Method Combination: The ComputeEffectiveMethod logic builds a nested execution chain following the Standard Method Combination rules:
   • :around methods are called first, with call-next-method progressing to the next around method or the main chain.
   • The main chain executes all :before methods, the primary method, and finally all :after methods in reverse order.
4. Fast Invocation: The resulting effective method is compiled into a Func<object[], object> that uses direct delegate invocation to minimize overhead.

Challenges and Solutions

1. Thread-Safe Non-Local Exits (call-next-method)

Challenge: call-next-method and next-method-p require access to the current invocation's state (the remaining methods and original arguments). Passing this state through every function call would break compatibility with standard Lisp function signatures.

Solution: CLRHack utilizes [ThreadStatic] fields in MopRuntime to store the currentNextMethods and currentArguments. This ensures that even in highly concurrent environments (like a web server), each OS thread has its own isolated invocation context, allowing call-next-method to function correctly without state leakage.

2. Forward References and Lazy Finalization

Challenge: Lisp allows classes to refer to superclasses that haven't been defined yet. The runtime must handle these "zombie" classes without crashing the JIT compiler.

Solution: The system implements a ForwardReferencedClassMetaobject. When a class is defined, it is automatically finalized (computing its CPL and slot layout). If a superclass is missing, a forward reference is created. The EnsureFinalized protocol ensures that inheritance is resolved and slot locations are assigned the moment the class is first instantiated or used in dispatch.

3. Performance Overhead of the "MOP Bridge"

Challenge: A naive implementation of slot-value or generic dispatch using C# reflection or linear searches is orders of magnitude slower than native C# member access.

Solution: Three distinct optimizations were applied:

• O(1) Slot Access: Each ClassMetaobject maintains a SlotDictionary. Slot names are mapped to physical array indices during finalization, allowing slot-value to perform a direct array access after a single dictionary lookup.
• Compiler Primitives: The compiler identifies SLOT-VALUE and MAKE-INSTANCE calls and emits direct CIL call instructions to optimized Lisp.MopRuntime methods, bypassing the general Funcall path.
• Zero-Allocation Cache Hits: By making InvocationCacheKey a readonly struct and avoiding the cloning of the argument array during cache probes, the hot-path for generic function dispatch generates zero garbage for the .NET Collector.

4. Bootstrapping the COMMON-LISP Package

Challenge: Core CLOS functions like make-instance must be available as symbols in the COMMON-LISP package before user code runs, but they rely on the MOP runtime being fully initialized.

Solution: A MopRuntime.Initialize() method is injected into the entry point (Main) of every generated assembly. This method interns the necessary symbols and binds them to GenericFunctionClosureAdapter objects, ensuring that the MOP is "alive" before the first line of Lisp code executes.

---

Vibe coding the MOP basically involved feeding chapters 4 and 5 of the Art of the Meta-Object Protocol into the LLM and telling it to make an implementation plan. It came up with a twenty-step plan to bootstrap CLOS. I then spent the rest of the day instructing an agent to take on each task of the twenty-step plan in sequential order. At the end of the day, I had a working MOP

This is the end of my series of posts on CLRHack.

31 May 2026 7:00am GMT

Implementation of SIGNAL and ERROR in CLRHack

In CLRHack, the condition signaling system is implemented in the Lisp.HandlerControl class within the LispBase library. It leverages .NET's [ThreadStatic] storage to maintain a per-thread dynamic stack of active condition handlers.

SIGNAL Implementation

The Signal(object condition) method performs the following logic:

1. Retrieval: It fetches the activeHandlers list for the current thread. This list is a chain of [LispBase]Lisp.Handler objects maintained by handler-bind.
2. Iteration: It iterates linearly through the list from the most recently bound handler to the oldest.
3. Type Matching: For each handler, it calls IsType(condition, handler.ConditionType).
   • If the condition is a symbol, it checks for symbol equality (supporting simple symbol-based conditions).
   • If the condition is a .NET object, it checks if the handler's type is assignable from the condition's runtime type (supporting interop with system exceptions).
   • It treats the symbols T or EXCEPTION as catch-all types.
4. Handler Invocation: If a match is found:
   • Recursive Signal Protection: Before calling the handler function, the current handler list is temporarily shadowed. activeHandlers is set to cell.rest (the handlers bound outside the current one). This ensures that if the handler itself calls signal, it won't trigger itself recursively.
   • Execution: The handler's Closure is invoked with the condition object as its argument.
   • Restoration: A finally block ensures the original activeHandlers list is restored if the handler returns normally.

   ERROR Implementation

   The Error(object condition) method build upon Signal:

   1. Signaling Pass: It first invokes Signal(condition). If a handler performs a non-local exit (e.g., via handler-case), the Error method never returns.
   2. Debugger Entry: If Signal returns normally (meaning all handlers declined), Error calls EnterDebugger(condition).
   3. Interactive Debugging: The debugger:
      • Prints the condition and a list of available restarts (retrieved via RestartControl.GetActiveRestarts()).
      • Provides a prompt for the user to select a restart, launch the system-level debugger (Visual Studio/Rider), or abort.
      • If a restart is selected, it is invoked interactively (potentially gathering arguments from the user).
   4. Final Fallback: If the debugger is exited without invoking a restart, Error throws a C# Exception to ensure that execution does not continue on an invalid path.

   Notable Implementation Decisions and Edge Cases

• Handler Shadowing: The decision to pop the handler list during invocation is critical for maintaining Common Lisp semantics. It prevents infinite loops and ensures that "outer" handlers can handle errors raised within "inner" handlers.
• Unified Exception Model: CLRHack attempts to unify Lisp conditions and .NET exceptions. IsType allows Lisp handlers to catch C# exceptions by their class name or Type object.
• Thread Isolation: By using [ThreadStatic] for activeHandlers, CLRHack ensures that condition signaling is thread-safe. One thread signaling an error will not interfere with the handler state of another thread.
• Debugger Capability: The SYSTEM-DEBUGGER option in EnterDebugger is a bridge to the underlying .NET environment, allowing developers to use professional IDE tools to inspect the state of the Lisp VM when an unhandled error occurs.

signal and error complete the Common Lisp condition system implementation for CLRHack

30 May 2026 7:00am GMT

All video recordings from FOSDEM 2026 that are worth publishing have been processed and released. Videos are linked from the individual schedule pages for the talks and the full schedule page. They are also available, organised by room, at video.fosdem.org/2026. While all released videos have been reviewed by a human, it remains possible that one or more issues fell through the cracks. If you notice any problem with a video you care about, please let us know as soon as possible so we can look into it before the video-processing infrastructure is shut down for this edition. To report any舰

25 Apr 2026 10:00pm GMT

Are you ready for another challenge? We're excited to host the second yearly edition of our treasure hunt at FOSDEM! Participants must solve five sequential challenges to uncover the final answer. Update: the treasure hunt has been successfully solved by multiple participants, and the main prizes have now been claimed. But the fun doesn't stop here. If you still manage to find the correct final answer and go to Infodesk K, you will receive a small consolation prize as a reward for your effort. If you're still looking for a challenge, the 2025 treasure hunt is still unsolved, so舰

29 Jan 2026 11:00pm GMT

With FOSDEM just a few days away, it is time for us to enlist your help. Every year, an enthusiastic band of volunteers make FOSDEM happen and make it a fun and safe place for all our attendees. We could not do this without you. This year we again need as many hands as possible, especially for heralding during the conference, during the buildup (starting Friday at noon) and teardown (Sunday evening). No need to worry about missing lunch at the weekend, food will be provided. Would you like to be part of the team that makes FOSDEM tick?舰

26 Jan 2026 11:00pm GMT