leo60228

In that case, you probably don't want to be using Rust on AVR, especially on a currently unsupported platform like the Nano Every. It's currently very early. Hopefully it'll improve...

These (pretty hacky) changes shave about 20% off my program's runtime: ```diff diff --git a/Cargo.toml b/Cargo.toml index 56112ea..221e445 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -23,6 +23,7 @@ matches = "0.1.6"...

Now that I think about it, most programs bottlenecked by parsing will likely be parsing *many* HTML documents. I wonder if having a thread-local `RefCell` where the `HashSet`s are cloned...

> Now that I think about it, most programs bottlenecked by parsing will likely be parsing _many_ HTML documents. I wonder if having a thread-local `RefCell` where the `HashSet`s are...

https://github.com/billziss-gh/winfsp/issues/94 is implementing the FUSE low-level API as a Windows driver.

WinFSP seems to have active development on this, but I'm not sure if it's in a usable state.

All JPEG files are valid MJPEG frames, but the other way around isn't true. Most cameras will give valid JPEG files when asked to output MJPEG frames, but this isn't...

```c #include #include uint32_t mjpg_to_jpg(uint8_t *mjpg, uint32_t mjpg_size, uint8_t *jpg) { static uint8_t huffman[] = { 0xff, 0xc4, 0x01, ... , 0xfa }; uint32_t i = 0; while (!(mjpg[i] ==...

If you can't read C, that puts a (truncated in that snippet) array before the first occurrence of 0xffc0.

The full array is at https://github.com/lightbits/usbcam/blob/master/mjpg_to_jpg.cpp#L28-L64.