Laurent Mazare

Certainly agree with your point that the `f_XX`, `XX`, `XX_`, and now `XX_s` functions is far from ideal. If it was only functions and not methods on the tensor type,...

Thanks for reporting this. Since a couple version, the way to link cuda in the libtorch C++ library has changed and relies on specific linker flags, so I opened this...

Ah glad that you were able to get this to work, it's annoying that this bit is optimized away in release mode. Fwiw the flags that should help with this...

Yes there will be a better solution once `extra-link-args` has been stabilized for long enough, this has already been tested in #330 . The flag should hopefully be stable in...

This should be stable in the upcoming 1.56 Rust release. https://github.com/rust-lang/cargo/pull/9557

Looking at the compilation failures above, it seems that the tch-rs code is compiled for arm64 but tries to link with x86 binaries for libtorch. The libtorch binaries are automatically...

I don't think there is any equivalent for this at the moment: the current api is mostly generated automatically from the [declarations.yaml](https://raw.githubusercontent.com/LaurentMazare/tch-rs/master/third_party/pytorch/Declarations-v1.5.0.yaml) file and I haven't found anything related in...

Thanks for reporting this issue, indeed `cu113` seems to work fine so the build script has been updated to reflect this.

@Mec-iS that's odd. I just tried with the latest github tip and `TORCH_CUDA_VERSION=cu116` and it worked well. Is it possible that you were using an older version of this crate...

Support for `cu116` was added after the crate 0.8.0 release so this explains the error you saw, the next version will have a better error message for this.