-
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding optional tracing #328
Comments
Thank you for your issue! I'm unsure about it being a compile-time feature due to it creating a lot of code complexity. I think we can start with it included by default, and then run benchmarks on how much impact it would have, that would give us an informed opinion of the cost of having it there but not in use. |
|
tracing is no_std. https://docs.rs/tracing/latest/tracing/#crate-feature-flags |
It is, but it cannot do anything useful without subscriber? E.g. write logs to file or print to |
Right, but we're a library, we don't need to setup a subscriber. Applications setup the subscriber. |
Yeah, I think I was too focused on some easy default. I can try to implement this without subscriber at some point by using tracing crate. |
Yeah, you don't want to have a subscriber in the library because you want to give applications the maximum flexibility of where they log to. We can of course setup the benches and some tests with a subscriber of course for our own debugging. |
For debugging purposes, it would be exceptionally useful if we add, for example tracing support as an optional compile-time feature. It will come with performance cost but reduces the need to split complex types for smaller parts to see what is wrong.
E.g. every encode/decode method could log the value, constraints, encoded length and encoded value bytes.
The text was updated successfully, but these errors were encountered: