profile
viewpoint
Malloc Voidstar AlyoshaVasilieva USA They/them

AlyoshaVasilieva/epub-builder 0

A Rust library for generating EPUB files

AlyoshaVasilieva/gifsicle 0

Create, manipulate, and optimize GIF images and animations

AlyoshaVasilieva/imxrt-rs 0

Rust for NXP i.MX RT

AlyoshaVasilieva/jumblr 0

Tumblr API v2 Java Client

AlyoshaVasilieva/lcdjava 0

Java client for LCDproc

AlyoshaVasilieva/mh-z19-rs 0

Winsen Infrared CO2 Module MH-Z19 serial "api" implementation in Rust.

AlyoshaVasilieva/pwned-rs 0

HaveIBeenPwned API 2.0 in Rust

AlyoshaVasilieva/stm32f4xx-hal 0

A Rust embedded-hal HAL for all MCUs in the STM32 F4 family

PR opened stm32-rs/stm32h7xx-hal

Add MCUDev DevEBox and WeAct MiniSTM32H7 to README

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.

+2 -0

0 comment

1 changed file

pr created time in 3 days

push eventAlyoshaVasilieva/stm32h7xx-hal

Malloc Voidstar

commit sha 7b3d1988716969fd778bc1ad8c28f43934c2d68d

Add MCUDev DevEBox and WeAct MiniSTM32H7

view details

push time in 3 days

create barnchAlyoshaVasilieva/stm32h7xx-hal

branch : mcudev-and-weact

created branch time in 3 days

delete branch AlyoshaVasilieva/stm32h7xx-hal

delete branch : weact

delete time in 3 days

push eventAlyoshaVasilieva/stm32h7xx-hal

Malloc Voidstar

commit sha d5aadef406e12a2d1bcb3cd4c151857d9a216f50

Add WeAct STM32H7 to readme

view details

push time in 3 days

create barnchAlyoshaVasilieva/stm32h7xx-hal

branch : weact

created branch time in 3 days

fork AlyoshaVasilieva/stm32h7xx-hal

Peripheral access API for STM32H7 series microcontrollers

fork in 3 days

issue openedWFCD/warframe-items

Drop chances are not consistently strings or doubles

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

created time in 4 days

issue openedgentoo90/winreg-rs

OsString::from_reg_value shouldn't preserve null terminator

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.

created time in 4 days

issue commentJimmXinu/FanFicFare

De-duplicate downloaded images (mostly for fiction.live)

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

AlyoshaVasilieva

comment created time in 10 days

issue openedJimmXinu/FanFicFare

fiction.live: unhashable type: 'dict'

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.

created time in 12 days

issue commentJimmXinu/FanFicFare

De-duplicate downloaded images (mostly for fiction.live)

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):

Story Initial size De-duplicated size
Star Wars: The Chosen 7.01MB 6.02MB
Your Hero Academia 7.4MB No duplicates
A Shadow Resides 27.9MB 23.4MB
Fate/Grand Quest 28.6MB 25.1MB
Dictator Quest 10.8MB 10.6MB
EUN-1CE 4.33MB 4.11MB

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).

AlyoshaVasilieva

comment created time in 12 days

issue openedJimmXinu/FanFicFare

De-duplicate downloaded images (mostly for fiction.live)

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.)

created time in 12 days

startedkellerkindt/w5500

started time in 13 days

delete branch AlyoshaVasilieva/stm32f4xx-hal

delete branch : derive-debug

delete time in 14 days

PR opened stm32-rs/stm32f4xx-hal

Derive Debug for times

Matches f1xx, h7xx, probably other HALs.

+5 -5

0 comment

1 changed file

pr created time in 16 days

push eventAlyoshaVasilieva/stm32f4xx-hal

Malloc Voidstar

commit sha 5bebe964398984541fb75646f9e7f9ccf57bb2df

Derive Debug for times

view details

push time in 16 days

create barnchAlyoshaVasilieva/stm32f4xx-hal

branch : derive-debug

created branch time in 16 days

fork AlyoshaVasilieva/stm32f4xx-hal

A Rust embedded-hal HAL for all MCUs in the STM32 F4 family

fork in 16 days

startedmaikelwever/nrf24l01

started time in 20 days

startedstm32-rs/stm32-rs

started time in a month

startedstm32-rs/stm32h7xx-hal

started time in a month

startedstm32-rs/stm32f4xx-hal

started time in a month

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

@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.

AlyoshaVasilieva

comment created time in 2 months

issue commentcyd01/KiTTY

kitty-bin-0.74.0.2.zip currently on virustotal: 14 engines detected this file

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

cebaa

comment created time in 2 months

issue commentrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

> $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.

AlyoshaVasilieva

comment created time in 2 months

startedlise-henry/epub-builder

started time in 2 months

issue openedlise-henry/epub-builder

Library doesn't allow metadata with multiple values

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:

Element Reason
creator Multiple authors
subject Multiple genres/tags
identifier Different opf:schemes (uuid, ISBN, Amazon, ...)

It would be useful for this library to allow this.

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

created time in 2 months

push eventAlyoshaVasilieva/epub-builder

Elisabeth Henry

commit sha cc70933d5e6248fca62ce17606d4ebbd2ce2c4c4

Sanitize HTML in titles when writing toc.ncx

view details

Elisabeth Henry

commit sha a6b13d5fd69b4224ba9f1185cb1fd0370cf00b09

Convert HTML to text, but correctly

view details

Elisabeth Henry

commit sha 64de16903b1ab87bad0294f167c4e5f26644d891

Reference cover-image instead of the file in EPUB2 cover metadata

view details

Elisabeth Henry

commit sha def2f0bd4eefd9be839cead8782d454d36191fc6

Add pretty assertions when testing

view details

Elisabeth Henry

commit sha 4f16182e336a6209174221b5c051f56bc31021b1

Update ChangeLog

view details

Elisabeth Henry

commit sha 68b470422255c96607a0f53d031bd0f6998e5328

Update uuid dependency

view details

Elisabeth Henry

commit sha b3e4594774ca1e7f43958a4fe32783aff8d47db4

Bump version to 0.4.5

view details

Paul Kernfeld

commit sha 98f0047730a772ee03665ee9e8f78da3edaa79fc

Add missing ? after ZipLibrary::new() With this change, I was able to successfully build and run the README example code

view details

Élisabeth Henry

commit sha 4433c11b2eb19da69b79c4a296ecb9e9344fee0a

Merge pull request #7 from paulkernfeld/patch-1 Add missing ? after ZipLibrary::new()

view details

Elisabeth Henry

commit sha 6e5354b3380401983aca808629733cfcc41f4f88

Also add missing ? after ZipLibrary::new() in srl/lib.rs

view details

Paul Kernfeld

commit sha 09107296f0b4b325535c63643920ab6916f24487

Valid XHTML as dummy content

view details

Élisabeth Henry

commit sha 7cd3924d8ea4662a8a143819133639414621c4d0

Merge pull request #9 from paulkernfeld/valid-dummy-content Valid XHTML as dummy content

view details

Elisabeth Henry

commit sha 53ca88953305b9c011d5259e23e92919f6d280a6

Bump version to 0.4.6

view details

Elisabeth Henry

commit sha 7ab01be8a33f826a0bb857aa411f1de9f9e3d0ed

Fix issue with some readers Some readers (e.g. Kobo Aura) have a problem reading the zip file if it has a comment set, so setting it to none should make the epub readable. Should fix #10

view details

push time in 2 months

issue closedimage-rs/image

Encoding 1-pixel L8 BMP requires infinite RAM on Windows 10 x64

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:

Rust version Works?
1.45 (LLVM 10.0) No
1.44.1 No
1.43.1 Yes (?!)
1.42.0 No
1.41.1 No
1.40.0 No
1.39.0 No
1.38.0 (LLVM 9.0) No
1.37.0 Yes
1.36.0 Yes
1.35.0 Yes
1.34.0 Yes

closed time in 2 months

AlyoshaVasilieva

issue openedrust-lang/rust

LTO triggers apparent miscompilation on Windows 10 x64

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:

Rust version Works?
1.45 (LLVM 10.0) No
1.44.1 No
1.43.1 Yes
1.42.0 No
1.41.1 No
1.40.0 No
1.39.0 No
1.38.0 (LLVM 9.0) No
1.37.0 Yes
1.36.0 Yes
1.35.0 Yes
1.34.0 Yes

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.

created time in 2 months

issue commentimage-rs/image

Encoding 1-pixel L8 BMP requires infinite RAM on Windows 10 x64

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());
}

AlyoshaVasilieva

comment created time in 2 months

issue openedimage-rs/image

Encoding 1-pixel L8 BMP requires infinite RAM on Windows 10 x64

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:

Rust version Works?
1.45 (LLVM 10.0) No
1.44.1 No
1.43.1 Yes (?!)
1.42.0 No
1.41.1 No
1.40.0 No
1.39.0 No
1.38.0 (LLVM 9.0) No
1.37.0 Yes
1.36.0 Yes
1.35.0 Yes
1.34.0 Yes

created time in 2 months

startedrust-embedded/embedded-hal

started time in 3 months

issue openedimxrt-rs/imxrt-rs

Support iMXRT1062 TRNG

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.

created time in 3 months

push eventAlyoshaVasilieva/imxrt1062-trng

Malloc Voidstar

commit sha f93384eaa091d58b6f207cd8c6b1e7b2a1a6a014

Remove pointless masks

view details

push time in 3 months

push eventAlyoshaVasilieva/imxrt1062-trng

Malloc Voidstar

commit sha e8c4c3846ba6579be852d53cfc9506389d994eb9

TRNG support

view details

push time in 3 months

create barnchAlyoshaVasilieva/imxrt1062-trng

branch : master

created branch time in 3 months

created repositoryAlyoshaVasilieva/imxrt1062-trng

iMXRT1062 TRNG

created time in 3 months

issue openedrust-embedded/cargo-binutils

Error when llvm-tools-preview not installed could be clearer

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.

created time in 3 months

issue openedmciantyre/teensy4-rs-template

Compilation fails

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

created time in 3 months

more