Skip to content
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

Add a logging framework #89

Closed
caspark opened this issue Dec 14, 2024 · 0 comments · Fixed by #93
Closed

Add a logging framework #89

caspark opened this issue Dec 14, 2024 · 0 comments · Fixed by #93
Labels
enhancement New feature or request

Comments

@caspark
Copy link
Contributor

caspark commented Dec 14, 2024

What

Add a logging framework of some kind.

Why

  • 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant