The Problem

I am using SvelteKit and importing a WebAssembly module on the server side inside a +page.server.ts file like this:

const WasmPromise = import('src/viz/wasmComp/geoscript_repl').then(
  async (engine) => {
    await engine.default(fetch('/geoscript_repl_bg.wasm'));
    return engine;
  }
);

It works when I run for local development, but it fails when running on my VPS in production. Some notes about my deployment environment:

• I’m Sveltekit’s adapter-node
• I’m deploying the Sveltekit app inside Docker behind an NGINX reverse proxy

This Wasm module as built using wasm-bindgen for Rust, and it needs the path to the Wasm to be explicitly provided since it’s running on the server side rather than the client.

The Problem

I was recently working with some Postgres tables that have an ltree column. I had written tests for my new feature that made use of them and all the tests passed locally.

However, the tests were failing in CI with a vague error:

ERROR: ltree syntax error at character 9 (SQLSTATE 42601)

The query that was producing this error was quite simple as well:

INSERT INTO "my_table" ("path","value") VALUES ('22e8f4e1-437f-448b-a8fb-0d7fbed8de7a','foo')

In this case, the path column was of type ltree. Running that exact query locally worked fine and I was confused as to why it wasn’t working in CI.

The Problem

I have two monitors: my main one at 165hz and a side monitor at 60hz. When I first boot up my computer, I’m able to run web-based games and visualizations at full 165hz on my main monitor.

However, after I turn my monitors off for the night and then get back on the next morning, all my WebGL-based applications are locked to 60 FPS or lower (and they feel stuttery and generally worse than even what I’d expect from stable 60 FPS)

The Problem

I dual-boot multiple Linux installs along with Windows. At some point, possibly coinciding with an update to one of my Linux installs, my Windows partition failed to boot with a bluescreen error showing a WHEA_UNCORRECTABLE_ERROR error message. I tried booting multiple times with no success.

Most info I found online about this error seemed to indicate that it was related to hardware issues, but I hadn’t made any hardware changes recently and my Linux installs continued to boot and work fine.

Background

I’m working on a browser-based game engine that uses Three.JS for rendering and a WebAssembly port of the Bullet physics engine called ammo.js for its physics engine and character controller.

Bullet is a very old physics engine and Ammo.JS is more or less a direct copy of it with a few changes to support usage in the browser. There are a lot of rough edges and things you have to figure out yourself in order to use it.

I recently finished some work involving constrained bezier curves for use in my browser-based digital audio workstation. Specifically, I used them in its envelope generator, which looks like this:

The circles are draggable handles that allow the user to create whatever shape they desire for the envelope. The green handles define the start and end point of each curve segment and the blue circles control its shape/steepness.

The Problem

In my project built with Rust compiled to WebAssembly, I started seeing errors like this that caused a crash - but only when it was compiled in debug mode:

wavetable.wasm-011dbbd6:0x17b89 Uncaught RuntimeError: memory access out of bounds
    at wavetable.wasm._ZN9wavetable2fm7effects14EffectInstance10from_parts17h321e4433e1216e56E (wavetable.wasm-011dbbd6:0x17b89)
    at wavetable.wasm._ZN9wavetable2fm7effects11EffectChain10set_effect17h969349e414104e9eE (wavetable.wasm-011dbbd6:0x1ba60)
    at wavetable.wasm.fm_synth_set_effect (wavetable.wasm-011dbbd6:0x314d3)
    at FMSynthAWP.port.onmessage (FMSynthAWP.js:171:37)

When compiling in release mode, the code ran just fine.

The decompiled debug-mode Wasm at the point of the crash looked like this:

I have some very basic Cypress tests set up for one of my personal projects - a single-page application created with React. I have some simple Github Actions configured to automatically run those tests every time I push to the repository.

At some point somewhat randomly, those tests started failing in CI. It was probably due to some dependency getting upgraded or a change in the environment in which Github Actions runs. The tests still ran fine locally when using the same commands and configuration, though, and I struggled to figure out why.

I’ve recently set up a Bluesky Personal Data Server (PDS) to store the data for my Bluesky account. I wanted to host it on my server alongside the many other web apps, databases, and many other services. I additionally wanted to use my top-level domain as my handle.

I started out following the install guide on the official PDS repo and it initially started out pretty well. However, I pretty quickly ran into some issues where the default config didn’t work for me.

The Problem

I was working on a screen-space reflection shader. This involves reading pixels out of the main scene’s framebuffer/texture to be reflected.

I was seeing strange grainy-looking artifacts showing up in my reflections that I couldn’t trace to anything in my shader code. Here’s what they looked like: