Comments for Matthew Petroff

Comment on Space-efficient Embedding of WebAssembly in JavaScript by Matthew Petroff

Matthew Petroff — Sat, 14 Feb 2026 21:58:54 +0000

In reply to Aidan Chelig. The Compression Streams API has been widely available since 2023, which provides gzip / deflate decompression and makes this technique obsolete. However, it still only exposes a subset of the browser's decompression functionality, as Brotli and Zstandard are widely supported for compression of HTTP responses, but they are not supported by the Compression Streams API in most browsers.

Comment on Space-efficient Embedding of WebAssembly in JavaScript by Aidan Chelig

Aidan Chelig — Tue, 10 Feb 2026 20:16:28 +0000

this is so funny and cool! I wonder if browsers will ever expose the decompression implementations to js, i remember asking this question a while ago when i was downloading and unpacking zips in the browser with a npm library. the mechanism is there in every browser, why not let us utilize it?

Comment on Canoeing the Park River Under Hartford by Jeffrey Facey

Jeffrey Facey — Sun, 10 Aug 2025 20:07:56 +0000

Thanks for the article. Extremely interesting. I grew up in West Hartford.

Comment on Perambulations and Town Lines by Toby O'Brien

Toby O'Brien — Mon, 17 Mar 2025 00:16:38 +0000

Hi! I only just learned about “beating the bounds” folklore today and was surprised to find Connecticut listed in Wikipedia as having carried it out for centuries. What a bummer to discover it has been discontinued on the same day when I learned of its existence.

I’ve been keen on the history of the Connecticut Notch (No, I won’t call it the Southwick Jog!)and I imagine it must have been a sore point for both sides back in the day.

Thanks for the article!

Comment on Automatic Camera Clock Synchronization under Linux by Wilhelm Spickermann

Wilhelm Spickermann — Mon, 03 Feb 2025 08:10:30 +0000

I have a similar problem with a “Canon Powershot SX70HS” using OpenSuse Leap 15.6.

gphoto2 –set-config datetimeutc=now

synchronized the camera (using “datetimeutc” without setting TZ).

But checking the time by taking a picture of a precise clock revealed a difference of 1.3 seconds and 1.6 seconds on the next try. That’s worse than setting by hand. Never expected that!

As the KDE clock seconds display is delayed rather often, I’ve used a program I’ve written in Ada which also shows two digits below the seconds without obscuring these digits by a too long exposure time of the camera. The program was tested against
xclock -digital -update 1 -strftime “%Y-%m-%d %H:%M:%S”

So the clock pictures taken allow the comparison of times including the EXIF “subsecond” variable.

So I’ll continue to use clock pictures and use exiftool for time correction of the pictures taken.