While trying to update my Mastodon server to the latest v4.2.0 release, I kept running into build failures when running docker-compose build. I got errors like this in the logs:

#20 27.04 Bundler 2.4.10 is running, but your lockfile was generated with 2.4.13. Installing Bundler 2.4.13 and restarting using that version.
#20 27.21 There was an error installing the locked bundler version (2.4.13), rerun with the `--verbose` flag for more details. Going on using bundler 2.4.10.
#20 27.29 Could not load OpenSSL.
#20 27.29 You must recompile Ruby with OpenSSL support.

It was very confusing since the official CI builds seemed to be working fine. Nevertheless, there were multiple issues opened about this, so it’s something people were running into.

I’ve been working on building 3D scenes and environments in the browser using Three.JS. As part of those, I make pretty heavy use of the pmndrs postprocessing library for post-processing and effects.

I’ve also implemented a custom godrays effect that works with postprocesing called three-good-godrays. It creates a custom pass that is added to the postprocessing EffectComposer which renders volumetric screen-space godrays by reading the depth buffer and shadow map for a light.

The Issue

When building my SvelteKit project, I get lots of errors like this in my console:

ERROR in ./src/graphEditor/nodes/CustomAudio/MIDIToFrequency/MIDIToFrequencySmallView.svelte
Module build failed (from ./node_modules/svelte-loader/index.js):
ReferenceError: performance is not defined
    at now (/home/casey/web-synth/node_modules/svelte/compiler.cjs:7:31)
    at new Stats (/home/casey/web-synth/node_modules/svelte/compiler.cjs:47:21)
    at compile (/home/casey/web-synth/node_modules/svelte/compiler.cjs:45535:16)
    at injectVarsToCode (/home/casey/web-synth/node_modules/svelte-preprocess/dist/transformers/typescript.js:85:45)
    at mixedImportsTranspiler (/home/casey/web-synth/node_modules/svelte-preprocess/dist/transformers/typescript.js:257:26)
    at transformer (/home/casey/web-synth/node_modules/svelte-preprocess/dist/transformers/typescript.js:336:11)
    at transform (/home/casey/web-synth/node_modules/svelte-preprocess/dist/autoProcess.js:46:12)
    at async /home/casey/web-synth/node_modules/svelte-preprocess/dist/autoProcess.js:117:29
    at async script (/home/casey/web-synth/node_modules/svelte-preprocess/dist/autoProcess.js:147:33)
    at async process_single_tag (/home/casey/web-synth/node_modules/svelte/compiler.cjs:45984:21)
    at async Promise.all (index 0)
    at async replace_in_code (/home/casey/web-synth/node_modules/svelte/compiler.cjs:45708:23)
    at async process_tag (/home/casey/web-synth/node_modules/svelte/compiler.cjs:46001:26)
    at async preprocess (/home/casey/web-synth/node_modules/svelte/compiler.cjs:46059:25)

They’re originating from within the Svelte compiler.

I bumped several of the dependencies for one of my projects. It uses Svelte and Webpack, and makes use of svelte-loader to facilitate importing .svelte files.

I upgraded Svelte from v3.57.0 to v4.2.0, and bumped svelte-loader, svelte-preprocess, prettier-plugin-svelte, and many other libraries to their latest versions as well.

After the upgrade, my Webpack dev server started up but failed to load with many errors like these displayed in the console:

I’ve been using a tool called radeontop for years to monitor the performance and utilization of my AMD GPUs on Linux. It’s a TUI-based application that renders the value of different performance counters as bar charts:

For the most part, it does a good job and it provides a concise overview of GPU utilization.

I’m picking back up the work that I started last year building 3D scenes and sketches with Three.JS.

At that time, it was just after AI image generators like DALL-E and Stable Diffusion were really taking off. I had success running Stable Diffusion locally and using it to generate textures for terrain, buildings, and other environments in the 3D worlds I was building.

I was using Stable Diffusion v1 back then. I had found some prompts that I liked which created images with styles kind of like this:

I recently finished a big blog post about growing sparse computational graphs with RNNs.

An important part of that work involved creating a custom RNN architecture to facilitate the growth of extremely sparse networks. To help explain that custom RNN architecture in the blog post, I created some visualizations that looked like this:

These images are SVGs, so they scale infinitely without getting pixelated or blurry. I looked into a few different options for generating these including tools like draw.io, manually drawing them in a vector editor like Inkscape, and Graphviz.

UPDATE 2023-08-15:

Some engineers at Google reached out to me via e-mail after I submitted some feedback about this issue on the GCP console and linked to this blog post.

After a few back and forth messages, they were able to diagnose the problem and put out a mitigation that completely fixed it for us!

The issue seems to have stemmed from cursors tracking the position in the streaming buffer getting out of sync between the BI engine and base BigQuery.

I recently upgraded to a 7900 XTX GPU. Besides being great for gaming, I wanted to try it out for some machine learning.

It’s well known that NVIDIA is the clear leader in AI hardware currently. Most ML frameworks have NVIDIA support via CUDA as their primary (or only) option for acceleration. OpenCL has not been up to the same level in either support or performance.

That being said, the 7900 XTX is a very powerful card. It has 24GB of VRAM, a theoretical 60 TFLOPS of f32, and 120 TFLOPS of f16. The recent AI hype wave is also incentivizing AMD to beef ML support on their cards, and they seem to be making real investments in that space.

We ran into this error at my job at Osmos. We upload files to GCS using their JSON-based REST API. Everything was working just fine until we tried uploading a large-ish file of ~2.5GB.

We upload to this API route: https://storage.googleapis.com/upload/storage/v1/b/bucket-name/o?name=file_name.csv&uploadType=media

The Problem

When we tried to upload the data, we got a HTML page as a response with a 400 error code and this unhelpful error message:

400. That's an error.

Your client has issued a malformed or illegal request.  That's all we know.

The Fix

We were about to fix the issue by adding a Content-Length header to the request. It seems that for some requests, it isn’t necessary, but it is for others.