Akhil Velagapudi

One possible workaround is to fetch the zeromq sources independently and then override the path `zeromq-src`: ```nix let cargo_nix = callPackage ./Cargo.nix { defaultCrateOverrides = pkgs.defaultCrateOverrides // { libzmq-sys =...

Would https://github.com/mrhooray/crc-rs/pull/69 be sufficient for this? I can't really think of a use case where parameters other than `init` have to be generated dynamically.

If the list of possible algorithms is bounded, then could you create a const array of all the ones you want to test? Maybe with a const fn.

Any thoughts on how to expose this in the public API? Maybe `Crc` can be generic over the update implementation: ```rust struct Crc { pub algorithm: &'static Algorithm, crc_update: U,...

@0-wiz-0 `CRC_32_BZIP2` is a different algorithm from `CRC_32_IEEE`, try `CRC_32_ISO_HDLC` instead. Other than that your diff is correct, and should work. One performance nitpick: use `const crc: Crc = Crc::::new(&CRC_32_BZIP2);`...

> I also have a question about this. We were using: > > ``` > crc::crc64::checksum_ecma(&buf[..]) > ``` > > It _seems_ like this should be replace by: > >...

Is there a reason why we can't make the existing `update` function `const`?

I think this bumps the MSRV right? So, might require a major version release.

https://github.com/plotters-rs/plotters/issues/398 is causing tests to fail, maybe pin the version to v0.3.1?

A hacky workaround is to pre-process the migration file names. Sort the names by date and prefix them with integer IDs before feeding them into refinery. EDIT: Actually this might...