Better error if binary does not match version

[drahnr]

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: InvalidBoolEncoding(2)', src/checker/nlprules.rs:22:70

static TOKENIZER_BYTES: &[u8] = include_bytes!(concat!(env!("OUT_DIR"), "/tokenizer.bin"));
static RULES_BYTES: &[u8] = include_bytes!(concat!(env!("OUT_DIR"), "/rules.bin"));

lazy_static::lazy_static! {
    static ref TOKENIZER: Tokenizer = Tokenizer::from_reader(&mut &*TOKENIZER_BYTES).unwrap();
    static ref RULES: Rules = Rules::from_reader(&mut &*RULES_BYTES).unwrap(); /// <<< this one errors, and it's always this one
}

[drahnr]

CI failure https://ci.spearow.io/teams/main/pipelines/cargo-spellcheck/jobs/pr-validate/builds/546

[bminixhofer]

Which binaries are you using? This looks like an issue with an outdated binary.

At the moment I don't want to make any stability guarantees of the same binaries being usable across versions because things in the core are still prone to change quickly. So the binary for version 0.3.0 does not work with the latest commit to master.

I think the right course of action here is a better error message that informs which version of the binary you are using and which version of nlprule; that requires some sort of compatibility to read the version but that's doable.

In the meantime you can download the unreleased binaries for the latest commit to master at the corresponding GH action output: https://github.com/bminixhofer/nlprule/actions/runs/531964158

[drahnr]

If that's the case, then the helper API would really make sense, so issues like these won't pop up again, but compatibility is guaranteed by API.

[bminixhofer]

I agree 100%. Still it should also have a better error message and i. e. read the version as the first x bytes of the binary and if it does not match stop right away.

At the moment I'm working on #15 but a build.rs and from_lang_code (or equivalent) API will be part of the next release.

[bminixhofer]

I'll implement this soon. I think using the first 64 (or 128, 256, but I think 64 is enough) bytes of each binary to store the version encoded as UTF8 is the best way. I'm not too sure if there isn't maybe a more standard way so I'd appreciate a second opinion @drahnr :)

[drahnr]

I think kiss is the best approach here. Reserving 8 bytes and using them as big endian u64 for a running number and using a static var to reference this. As alternative, one could make the files part of an archive instead of just compressing them and adding two more entries/files, VERSION and GITSHA. The first one is leaner, but I'd prefer the latter, since the resulting format is inspectable with common tooling available.

[bminixhofer]

one could make the files part of an archive instead of just compressing them and adding two more entries/files, VERSION and GITSHA

Oh that's a good idea! I have to check how much overhead there is from tarring / untarring (also w.r.t dependencies) but if it's reasonably small then that's definitely a better approach.

[drahnr]

The rust cookbook contains a few examples which might be helpful https://rust-lang-nursery.github.io/rust-cookbook/compression/tar.html