Robert Knight

RTen in 2025

Wed, 31 Dec 2025 00:00:00 +0000

RTen is a machine learning runtime for Rust that was first released in December 2023. It enables you to take models that have been trained in Python (eg. using PyTorch) and run them in Rust. It supports models in ONNX format, which you can find many of on Hugging Face or export from frameworks such as PyTorch.

The project started out as a runtime for Ocrs, an OCR library and CLI tool. It has since evolved into a general purpose ONNX runtime which can run a wide variety of popular models across many domains (vision, audio, text, etc.). The current version only supports CPU inference, though I plan to change this next year.

The RTen machine learning runtime - a 2024 retrospective

Mon, 30 Dec 2024 00:00:00 +0000

RTen is a machine learning runtime for Rust that I have been working on since mid 2022. It allows you to take models that have been trained in Python, using a framework such as PyTorch or Keras and run them in a Rust project.

This includes many pre-trained models that are available on places such as Hugging Face. Models are first exported to ONNX which is a portable exchange format for models, then converted to a FlatBuffers-based format (.rten) which can be loaded more efficiently at runtime.

Shallow rendering revisited: Better unit tests for React/Preact components

Mon, 10 Feb 2020 00:00:00 +0000

In this post I will discuss the benefits of isolating tests for React/Preact UI components from the details of child components, and the various approaches that we looked at for our frontend projects at Hypothesis. I will explain why we settled on the approach that we did and provide links if you would like to use the same tools and techniques in your projects.

Why mock child components?

When writing unit tests for a module in an application, it is generally a good idea to isolate that module from its dependencies, or at least those which have significant complexity or cost in terms of runtime performance. Isolating such dependencies has several benefits:

Mocking ES6 and CommonJS modules with Babel

Sat, 29 Jun 2019 00:00:00 +0000

A common need when writing unit tests is to limit the scope of the code being tested and force certain code paths to be executed by mocking imported functions / classes etc. and controlling their outputs.

In an earlier post I wrote about how existing tools for mocking JavaScript modules work when using the Browserify bundler, and problems with it. In this blog post, I present the approach that we are currently using to mock modules in JavaScript code at Hypothesis.

Keeping reviewers happy when developing larger changes

Fri, 05 Apr 2019 00:00:00 +0000

The challenge

When developing a large change to a project, in a team that uses code review and frequent deployments, there is a conflict that often comes up:

There is uncertainty at the outset about what exactly will need to change and the best approach to take. This tends to demand being highly iterative while working on the code. You’ll find unforeseen complexities part-way through. You’ll figure out a better solution once you’ve got something working. You’ll make a mistake or a typo and need to make “fixup” commits to correct it.
At the end you want to present a result at the end which is easy to review, minimizes deployment risks, and provides a clear record of the rationale for past decisions for your future self and other team members. This demands delivering changes in small, clearly organized increments, as if you knew exactly what you needed to do beforehand and never made mistakes.

A development strategy

In this post I’m going to describe the workflow that I use to try and meet both these needs. The strategy is to optimize for being able to make changes quickly and easily at the start and get feedback that might result in significant changes early, yet makes the review and deployment steps easy later.

Browserify and dependency mocking

Thu, 28 Feb 2019 00:00:00 +0000

Update (2019-04-11) - After exploring various alternatives, I wrote a new Babel plugin to solve the problems outlined in this blog post.

Browserify is a tool that enables a collection of Node.js-style modules (aka. CommonJS) to be bundled together into a script file that can be loaded in the browser.

This post explores the structure of the JavaScript bundles that Browserify generates and how the proxyquireify package modifies the bundle to support mocking of require calls in tests. It assumes that you are familiar with creating modules in Node. Towards the end I explain some of the caveats with Proxyquireify’s approach and briefly explore alternatives.

Encrypting secrets in a Git repository using git-crypt

Thu, 08 Feb 2018 12:43:34 +0000

git-crypt provides a way to encrypt a subset of files in a Git repository such that only specific collaborators can decrypt them, while making it possible for everyone else to access the unencrypted files and perform standard Git operations on the repository. At Hypothesis we use this to store various secrets (API keys, passwords) in a “playbook” repository for use by developers involved in the operation of the web service, while making it possible for a wider audience of staff at the organisation to access and update other resources in the same repository.

Web request and database transaction integration with Pyramid and SQLAlchemy

Mon, 29 Jan 2018 16:45:17 +0000

I recently had to debug a thorny issue in Hypothesis with the integration between our web framework Pyramid and database ORM SQLAlchemy. This integration is responsible for ensuring that changes to business objects (annotations, users, groups) made when processing API requests or form submissions actually get persisted to the database. Understanding how this works from the existing documentation was not straightfoward. These are my notes on how the various pieces fit together.

SQLAlchemy is a Python database ORM which uses the Unit of Work design pattern. In UoW, changes made to database rows via manipulations of ORM objects are grouped into transactions, which are then either committed or rolled-back as an atomic unit. The application makes commands to the database via a “Session” object.

Notes on React Europe 2016

Sat, 04 Jun 2016 00:00:00 +0000

The second React Europe conference has just finished and this is a jotting-down of some thoughts on the conference and my favorite talks whilst the Parisian red wine and almond croissants clear out of my system.

The organizers are kindly putting up videos on YouTube as I write this.

The Conference

This was a two-day conference preceded by a hackathon kindly hosted by Mozilla and a welcome event hosted by Red Badger. It was well organized and ran smoothly, the main part consisted purely of 30 minute talks with a few lightning-talk spots. There was plenty of time in-between for discussions.

Optimizing Webpack build times and improving caching with DLL bundles

Sat, 06 Feb 2016 00:00:00 +0000

Webpack’s Dll and DllReference plugins are a way to split a large JavaScript project into multiple bundles which can be compiled independently. They can be used to optimize build times (both full and incremental) and improve caching for users by putting code which changes infrequently into separate “library” bundles. The term ‘Dll’ is short for Dynamically Linked Library which is a feature for native Windows applications that solves the same problem.

Understanding the QWidget layout flow

Thu, 21 Nov 2013 00:00:00 +0000

When layouts in a UI are not behaving as expected or performance is poor, it can be helpful to have a mental model of the layout process in order to know where to start debugging. For web browsers there are some good resources which provide a description of the process at different levels. The layout documentation for Qt describes the various layout facilities that are available but I haven’t found a detailed description of the flow, so this is my attempt to explain what happens when a layout is triggered that ultimately ends up with the widgets being resized and repositioned appropriately.