You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working on this codebase, I often find myself adding (e)println debug statements, which I then need to remove before PRing - even though often this logging would be useful to me or the next contributor further down the line.
There are some cases where it would be helpful to just warn the user of something suboptimal instead of failing an assert (and crashing the app) or silently doing something.
There's currently a println!() in P2PSession that's fairly easy to trigger with bad connections or conservative max_prediction_window, which a) is ugly and b) won't print anything on a wasm build.
Options
Some approaches:
A) the log crate. Simple and easy to use for clients with many backends/adaptors available, including one that pushes log messages to tracing (although the default output is kinda ugly, with a lot fields being included).
B) the tracing crate. It's more complicated, but also used by bevy out of the box, and given that bevy seems to be by far the most popular Rust game engine, that should probably count for a fair bit (and I say that even though I don't use bevy myself).
C) write a shim to abstract over both log and tracing (maybe someone has already done this?), and users enable a feature flag to choose which one they want.
I'm open to any of these really, with a slight preference to B as tracing is what I use in my game and it's simpler to only add support for one.
I have also already added a bunch of useful logging statements in my personal ggrs fork, so I can port them over in a PR that actually adds logging.
So, which approach do we want to go with?
The text was updated successfully, but these errors were encountered:
What
Add a logging framework of some kind.
Why
max_prediction_window
, which a) is ugly and b) won't print anything on a wasm build.Options
Some approaches:
log
messages totracing
(although the default output is kinda ugly, with a lot fields being included).bevy
out of the box, and given thatbevy
seems to be by far the most popular Rust game engine, that should probably count for a fair bit (and I say that even though I don't use bevy myself).I'm open to any of these really, with a slight preference to
B
astracing
is what I use in my game and it's simpler to only add support for one.I have also already added a bunch of useful logging statements in my personal ggrs fork, so I can port them over in a PR that actually adds logging.
So, which approach do we want to go with?
The text was updated successfully, but these errors were encountered: