Adds the MCUDev DevEBox and WeAct MiniSTM32H7 to the readme, relatively cheap development boards.

I've done the basic blinky test for both of these boards. In the case of the DevEBox, I tested the STM32H743VIT6 version.

I'd prefer to link to a documentation source for the DevEBox, rather than their Taobao store, but I cannot find any site they run other than their store. There's a MicroPython board definition repo by mcauser that documents some aspects of the board.

I didn't add it to the readme but the WeAct board has read-out protection enabled and I had to manually issue a mass erase command to be able to connect to it. STM32CubeProg's read unprotect command just disconnected the board from USB with no other effect.

Describe the bug Some items have string drop chances, some have doubles.

To Reproduce Look at the drop chances for /Lotus/Types/Items/Solaris/DebtTokenD (all strings) and /Lotus/Types/Items/MiscItems/Plastids (all doubles).

Try Ctrl-F in this file for "chance": " or "chance": 0

Expected behavior Drop chances should consistently be doubles.

Versions:

• Version: b6c71ff938c85db168a0cba8d965c9fbef9f50c1 (v1.1140.0)
• Access Method: Github

Example code:

use std::ffi::OsString;
use std::os::windows::ffi::OsStringExt;
use std::path::PathBuf;

use winreg::enums::HKEY_CURRENT_USER;
use winreg::RegKey;

fn main() {
    let base = RegKey::predef(HKEY_CURRENT_USER);
    let desktop = base.open_subkey(r#"Control Panel\Desktop"#).unwrap();
    // read using OsString
    let wallpaper: OsString = desktop.get_value("WallPaper").unwrap();
    let path = PathBuf::from(wallpaper);
    println!("Wallpaper exists? {}, path is {:?}", path.exists(), path);
    // read using String
    let wallpaper: String = desktop.get_value("WallPaper").unwrap();
    let path = PathBuf::from(wallpaper);
    println!("Wallpaper exists? {}, path is {:?}", path.exists(), path);
    // read manually
    let wallpaper = desktop.get_raw_value("WallPaper").unwrap();
    let mut raw: Vec<u16> = wallpaper
        .bytes
        .chunks_exact(2)
        .into_iter()
        .map(|c| u16::from_le_bytes([c[0], c[1]]))
        .collect();
    while raw.ends_with(&[0]) {
        raw.pop();
    }
    let path = PathBuf::from(OsString::from_wide(&raw));
    println!("Wallpaper exists? {}, path is {:?}", path.exists(), path);
}

On my machine this prints:

Wallpaper exists? false, path is "C:\\Users\\X\\AppData\\Local\\Packages\\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\\LocalState\\Assets\\0659d89079d32d12eab382d73089f7997f00ee80d8d6c053dc879e956600804b\u{0}"
Wallpaper exists? true, path is "C:\\Users\\X\\AppData\\Local\\Packages\\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\\LocalState\\Assets\\0659d89079d32d12eab382d73089f7997f00ee80d8d6c053dc879e956600804b"
Wallpaper exists? true, path is "C:\\Users\\X\\AppData\\Local\\Packages\\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\\LocalState\\Assets\\0659d89079d32d12eab382d73089f7997f00ee80d8d6c053dc879e956600804b"

(these may all print false on your machine as internally it caches elsewhere; I just needed a simpler repro)

The null terminator on the OsString causes the PathBuf to have a path to a non-existent file. As a result, I have to choose between using a String (lossy if Unicode is ill-formed) or manually turning the registry's bytes into an OsString (lossless but complex).

From the OsString docs:

OsString and OsStr bridge this gap by simultaneously representing Rust and platform-native string values, and in particular allowing a Rust string to be converted into an "OS" string with no cost if possible. A consequence of this is that OsString instances are not NUL terminated; in order to pass to e.g., Unix system call, you should create a CStr.

Thanks a ton! Appears to be working fine so far and now the F.L ebooks are smaller.

While experimenting with the new fiction.live support, I found this story that can't be downloaded: https://fiction.live/stories/Star-Wars-Twilight-of-the-Republic/zZMpSXnx8f7RxJnoa

Trying to download the story fails during metadata with status error and comment "unhashable type: 'dict'".

Story dates from early 2017 so I wouldn't be surprised if some remnant of an earlier version of the site's weird API is breaking it.

Size saved depends on the story. To test I grabbed some stories from F.L using FFF and manually removed duplicate images (note I have a larger-than-default image_max_size):

Entirely possible it's more effort than is worth it, especially since every other site I'm aware of either doesn't use images or expects users to provide their own hosting (leading to identical URLs).

fiction.live stories often have duplicate images in the downloaded epub, as every uploaded image will always receive a new URL, preventing simple deduping. If an author repeatedly reuses images this can significantly bloat the ebook.

Although they don't have the same URL, identical images will be byte-for-byte identical even after FanFicFare/Calibre image processing (resizing, grayscaling). Duplicates can therefore be detected by use of a fast cryptographic hash and only one copy kept in the ebook, all other sources rewritten to point to it.

This isn't by any means critical to supporting F.L, but it's nice to have smaller ebooks.

(I have an only-partly-functional F.L downloader written in Rust and I do this to keep sizes down; I use the BLAKE2 hash since it is fast and its length is configurable. Thanks for FanFicFare, it's the only way I read fanfics now.)

Matches f1xx, h7xx, probably other HALs.

@pnkfelix I believe the arg is being set correctly, because:

> $Env:RUSTFLAGS="-C llvm-args=-cvp-dont-add-nowrap-flags-GARBAGE-GARBAGE"
> cargo run --release
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -C llvm-args=-cvp-dont-add-nowrap-flags-GARBAGE-GARBAGE --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit code: 1)
--- stderr
rustc: Unknown command line argument '-cvp-dont-add-nowrap-flags-GARBAGE-GARBAGE'.  Try: 'rustc --help'
rustc: Did you mean '--cvp-dont-add-nowrap-flags'?

> $Env:RUSTFLAGS="-C llvm-args=-cvp-dont-add-nowrap-flags"
> cargo run --release
    Finished release [optimized] target(s) in 0.07s
     Running `target\release\bmp-minimal.exe`
memory allocation of 13421772800 bytes failederror: process didn't exit successfully: `target\release\bmp-minimal.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

If RUSTFLAGS wasn't being set properly, then the garbage arg wouldn't cause an issue.

Above is using Powershell; I also tried using cmd using your commands:

>set RUSTFLAGS=-Cllvm-args=-cvp-dont-add-nowrap-flags
>echo %RUSTFLAGS%
-Cllvm-args=-cvp-dont-add-nowrap-flags
>cargo run --release
   Compiling bmp-minimal v0.1.0 (C:\X\bmp-minimal)
    Finished release [optimized] target(s) in 4.46s
     Running `target\release\bmp-minimal.exe`
memory allocation of 13421772800 bytes failederror: process didn't exit successfully: `target\release\bmp-minimal.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

and received the same failure.

I see you are using Rust 1.44.1 in your example. I tried using that arg on Rust 1.44.1 and it does indeed cause a successful run. On 1.45, however, it fails with or without the arg.

Appears to be detecting klink.exe: https://www.virustotal.com/gui/file/91345c5bccf5e70cb0e7f09ebb1cb72999e3d8d1951581e1182f78c303a8439a/detection

> $Env:RUSTFLAGS="-C llvm-args=-cvp-dont-add-nowrap-flags"
> cargo run --release
   Compiling bmp-minimal v0.1.0 (C:\X\bmp-minimal)
    Finished release [optimized] target(s) in 2.39s
     Running `target\release\bmp-minimal.exe`
memory allocation of 13421772800 bytes failederror: process didn't exit successfully: `target\release\bmp-minimal.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
> rustc --version
rustc 1.45.0 (5c1f21c3b 2020-07-13)

Still fails on my end, unless I'm doing something wrong.

A number of* EPUB's metadata attributes allow repeated elements, for example to define multiple authors:

<dc:creator opf:role="aut">Terry Pratchett</dc:creator>
<dc:creator opf:role="aut">Stephen Briggs</dc:creator>

and multiple genres:

<dc:subject>Fantasy</dc:subject>
<dc:subject>Humour</dc:subject>

(or multiple tags, common in web fiction and fanfiction)

However, this library only allows one instance of each. It's not clear to me what use there is for repeating some of the elements (different languages?) but I checked ebooks I own and found that the following are commonly repeated:

It would be useful for this library to allow this.

*: See § 3.4.3 Metadata and particularly § 3.4.3.3 DCMES Optional Elements

Expected

Encoding a 1-pixel BMP should take very little RAM.

Actual behaviour

memory allocation of 26843545600 bytes failederror: process didn't exit successfully: `target\release\bug-repro.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

Reproduction steps

Cargo.toml:

[package]
name = "bug-repro"
version = "0.1.0"
authors = ["Malloc Voidstar <1284317+AlyoshaVasilieva@users.noreply.github.com>"]
edition = "2018"

[dependencies.image]
version = "=0.23.7"
default-features = false
features = ["bmp"]

[profile.release]
lto = true
codegen-units = 1

main.rs:

use image::ColorType;

fn main() {
    let mut out = Vec::with_capacity(51200);
    let mut encoder = image::bmp::BMPEncoder::new(&mut out);
    encoder.encode(&[1], 1, 1, ColorType::L8).unwrap();
    println!("out len: {}", out.len());
}

Command: cargo run --release

Output on an ARM SBC (aarch64-unknown-linux-gnu): out len: 1082

On both my Windows 10 machines it fails due to memory allocation error (25GB on one, 100GB on the other).

I'm not entirely sure this is a bug in image rather than Rust itself; I first noticed this when a project suddenly began failing on 1.45 but worked fine on 1.44.1. While the above minimized code fails on both 1.45 and 1.44.1, it succeeds on other versions:

I tried this code:

Cargo.toml:

[package]
name = "bmp-minimal"
version = "0.1.0"
authors = ["Malloc Voidstar <1284317+AlyoshaVasilieva@users.noreply.github.com>"]
edition = "2018"

[dependencies]

[profile.release]
lto = true
codegen-units = 1

main.rs:

use std::io::Write;

fn main() {
    let mut out = Vec::with_capacity(51200);
    for val in 0u8..=255 {
        out.write_all(&[val, val, val, 0]).unwrap();
    }

    for _ in (0..1).rev() {
        for _ in 0..1 {
            out.write_all(&[0]).unwrap();
        }
    }
    println!("{} bytes written", out.len());
}

(extremely minimized form of grayscale BMP encoding from image crate)

Command: cargo run --release

I expected to see this happen: 1025 bytes written

Instead, this happened:

memory allocation of 26843545600 bytes failederror: process didn't exit successfully: `target\release\bmp-minimal.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

Meta

rustc --version --verbose:

rustc 1.45.0 (5c1f21c3b 2020-07-13)
binary: rustc
commit-hash: 5c1f21c3b82297671ad3ae1e8c942d2ca92e84f2
commit-date: 2020-07-13
host: x86_64-pc-windows-msvc
release: 1.45.0
LLVM version: 10.0

It appears to work fine on ARM Linux in my limited testing.

This minimized form works/doesn't work on the following versions:

If the LTO and codegen-units settings are removed it works on all above versions.

I originally noticed this when a project that worked on 1.44.1 suddenly started failing with huge memory allocations on 1.45, so this table specifically applies to this repro, not whatever the underlying bug is.

Not a bug in image. New minimal form:

use std::io::Write;

use byteorder::WriteBytesExt;

fn main() {
    let mut out = Vec::with_capacity(51200);
    for val in 0u8..=255 {
        out.write_all(&[val, val, val, 0]).unwrap();
    }

    for _ in (0..1).rev() {
        for _ in 0..1 {
            out.write_u8(0).unwrap();
        }
    }
    println!("{} bytes written", out.len());
}

Expected

Encoding a 1-pixel BMP should take very little RAM.

Actual behaviour

memory allocation of 26843545600 bytes failederror: process didn't exit successfully: `target\release\bug-repro.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

Reproduction steps

Cargo.toml:

[package]
name = "bug-repro"
version = "0.1.0"
authors = ["Malloc Voidstar <1284317+AlyoshaVasilieva@users.noreply.github.com>"]
edition = "2018"

[dependencies.image]
version = "=0.23.7"
default-features = false
features = ["bmp"]

[profile.release]
lto = true
codegen-units = 1

main.rs:

use image::ColorType;

fn main() {
    let mut out = Vec::with_capacity(51200);
    let mut encoder = image::bmp::BMPEncoder::new(&mut out);
    encoder.encode(&[1], 1, 1, ColorType::L8).unwrap();
    println!("out len: {}", out.len());
}

Command: cargo run --release

Output on an ARM SBC (aarch64-unknown-linux-gnu): out len: 1082

On both my Windows 10 machines it fails due to memory allocation error (25GB on one, 100GB on the other).

I'm not entirely sure this is a bug in image rather than Rust itself; I first noticed this when a project suddenly began failing on 1.45 but worked fine on 1.44.1. While the above minimized code fails on both 1.45 and 1.44.1, it succeeds on other versions:

The iMXRT1062 (and other devices?) has a True Random Number Generator, which would be useful to support. Unfortunately almost all of its documentation is contained in the Security Reference Manual, which requires a licensing agreement with NXP. Based on the site's assumption that I have a designated salesperson, I suspect I wouldn't be approved to read the SRM (and I don't really want to sign an NDA).

However, the MCUXpresso SDK contains example code for the TRNG. Reading that was enough to get it working: https://github.com/AlyoshaVasilieva/imxrt1062-trng/blob/master/src/lib.rs

This would probably fit better as part of the HAL rather than a separate driver library, but even if I wasn't currently sick I'm not sure I'd be able to design it properly, so hopefully someone here finds it useful. It depends on rand_core so I don't have to worry about messing up the block generation.

Speed: about 15 minutes to generate 1MB of random data, at least in my test. Probably best to use it to seed a (CS)PRNG.

I switched a project of mine from stable Rust to nightly Rust recently, and it was very confusing when later I noticed cargo objcopy wasn't working. The error is:

Failed to execute tool: objcopy
The system cannot find the file specified. (os error 2)

I'd also renamed my project in the meantime, so I got stuck down a tangent trying to figure out how renaming my project broke objcopy, assuming that it wasn't able to find the build output, rather than objcopy itself. It'd be nice if it reminded the user to ensure llvm-tools-preview is present on the current toolchain.

cargo generate --git https://github.com/mciantyre/teensy4-rs-template --name hello-world
cd .\hello-world\
cargo build --release
[...]
error[E0433]: failed to resolve: could not find `interrupt` in `rt`
  --> C:\Users\X\.cargo\git\checkouts\teensy4-rs-32cd33027d5b365b\ca100f3\src\usb.rs:89:14
   |
89 | #[crate::rt::interrupt]
   |              ^^^^^^^^^ could not find `interrupt` in `rt`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0433`.
error: could not compile `teensy4-bsp`.

To learn more, run the command again with --verbose.

Presumably caused by https://github.com/mciantyre/teensy4-rs/commit/c062ff26eca247f7f78c5b69be455d7656a04aca