Closed grouville closed 6 months ago
Sorry for the dump as a draft π I preferred to share the work and dump the current thought process instead of remaining blocked on my own π
It's very good, @grouville, thanks a lot! I also prefer such workflow π€
I will replicate the generator in the C to solve the missing symbol issue and it should work fine after that π
Closing this PR, already merged without the GitHub GUI π Thanks again, @grouville !
Context
Tries to bring the
sz_generate
andrandomize
to RustDesign of the function implementation
As seen on the toml, you only rely on
core::ffi
lib, with no allocation, as well asno_std
Constraints encountered
On both your C and CPP implementations, you have two definitions:
This draft is only based on the in-place implementaiton as it allows me to avoid the allocation question: as you are in would rely on the
no_std
,std::Vec
is not possible, so the allocation of the returned string / vecalloc
crate ? Do you have any opinion on that, or did I miss something ?Also, I encountered a mutability issue around the traits, to ship the PR as a draft, I rely on this MutableStringZilla trait, but the aim would be to unify them. I tried, but some of the distance functions fail, need to dig a bit more.
My tests currently rely on a Vec, not a String, as the String doesn't comply with the
AsMut<N>
. In this case, to test the string, we would need to rely on the implementation returning a string or a vecCurrent issue
I am having an issue on the linker, which doesn't find the
I believe this is due to the fact that
sz_generate
is solely implemented in the.h
, making the FFI not find the function implementation ? I've been blocked tonight on it, any guidance would be helpful π Instead of relying just on sz_generate, shall I rely on the underlying functions and implement it directly in Rust ?Nonetheless, please tell me if I am totally not getting it ? π The aim is to iterate on the PR until the implementation