Is it possible to store to a NIF's rustler::Env instance in a struct that is a encoded/decoded using the NifStruct macro?

[aram0112]

I see that Decoder/Encoder are not implemented for Env. I am not concerned with actually encoding/decoding the Env, but simple storing a reference to it in a struct so that I can implement functions within that struct that can take advantage of the env's send function to communicate with the beam. Thank you!
`

[filmor]

You can't use an Env directly (without being constrained to the same "call"), but you can use an OwnedEnv instead.

[aram0112]

Thank you so much! I had another rust question generally if you would mind. I am fairly new to rust and my primary use case is to integrate rust into my Elixir application such that rust crates can be dynamically compiled and run during application runtime. The solution I've reached thus far is creating a NIF using Rustler and having that NIF load and call functions from crates using the libloading library. One weird quirk I have noticed, however, is that if a crate is re-compiled and my NIF function is called again, it uses an older version of the compiled crate even after it is re-compiled. If I copy the compiled crate to a different location and pass that location in to the NIF, the new version of the crate function is used. I was wondering if you might have any insight as to whether I could similar functionality in a more intuitive way, or whether there is anything I'm doing wrong or could do differently in order to not have to copy the crate to a different location. Thank you so much!

[filmor]

You have to explicitly reload the NIF module (and on Windows, that might not even be enough, you might need to rename the DLL). There is currently nothing in Rustler itself to handle this (e.g. we could add a hash to the file name on compiling or something like that).

[aram0112]

Interesting - just to be clear, in order to see the latest changes on an external, non-NIF crate that is being dynamically loaded by my NIF using libloading, I would need to reload the NIF crate itself. (Or I guess rename/move the non-NIF external crate as I currently am.

[filmor]

Hm, no, not really. Not sure what exactly libloading does, but its behavior should be independent from whether you use it in an executable or a NIF (which is just a shared library that is loaded by the BEAM in a module's on_load callback).

[aram0112]

Gotcha, I figured that the issue was unrelated to Rustler itself, was just trying to see if I was missing anything obvious. Thank you so much!