Michael Ilyin comments

Results 101 comments of


                                            Michael Ilyin

refactor: polish payload (de)serializationn with macro

Looks nice, but I have concerns about bindgen processing for the exported functions. Correct me if I'm wrong, but as far as I remember the bindgen can't extract "extern C"...

Bindings alingmemt

Lowering priority: only config for rust and take for callback parameters remains

provide "matching_status" function for publisher

this is unstable, low priority

create _Generic macro for type serializing functions

> It was my idea 😭 More seriously, we should also add a `z_bytes_deserialize` macro at the same time. Sorry!!! I've started typing from "J" and didn't noticed the continuation

create _Generic macro for type serializing functions

Serializing funcitons are better aligned in https://github.com/eclipse-zenoh/zenoh-c/issues/553 fixes. Now It would be nice to combine them functions under single macro/template

expose REPLY_KEY_EXPR_ANY_SEL_PARAM constant

decide is it external or internal API in rust, see https://github.com/eclipse-zenoh/zenoh/issues/806

expose REPLY_KEY_EXPR_ANY_SEL_PARAM constant

this is unstable, no need to be exposed now

expose REPLY_KEY_EXPR_ANY_SEL_PARAM constant

though we exposing some part of unstable API with`zcu_` prefix, but priority of this is less. So reopening the task with low priority

make rust analyzer's "go to definition" on C loaned, owned, etc. types go to corresponding `decl_c_type!(...)`

> I think the behavior as is is correct and does not need any change, if needed you can always search for something like "owned(z_owned_bytes_t". It's correct but not convenient....

Fix installation when ZENOHC_CUSTOM_TARGET is not set and CARGO_BUILD_TARGET env variable is set

I don't mind to the proposed logic: if CARGO_BUILD_TARGET is set then use it, but if ZENOHC_CUSTOM_TARGET is set it overrides the CARGO_BUILD_TARGET. There is only one update I'd like...