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.

Sign up for GitHub

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

Jump to bottom

tracing-tracy: replace baked-in config fields with a Config trait #91

Merged
merged 5 commits into from
Jan 28, 2024
Merged

tracing-tracy: replace baked-in config fields with a Config trait #91

merged 5 commits into from
Jan 28, 2024

Commits on Jan 27, 2024

  1. tracing-tracy: replace baked-in config fields with a Config trait 

    This allows users to more flexibly adjust the behaviour of the tracing
layer. My favourite examples are actually an ability to implement this
structure for some other serialization format that holds the
application-wide config. That way people do not need to litter their
application set up code with accesses to their configuration, conversion
and other concerns.

But with this if people want constant evaluation for performance
critical applications, now they can do it too.
    @nagisa
    nagisa committed Jan 27, 2024
    Configuration menu
    Copy the full SHA
    162bc2a View commit details
    Browse the repository at this point in the history

  2. config: enable customization of behaviour upon an error condition

    @nagisa
    nagisa committed Jan 27, 2024
    Configuration menu
    Copy the full SHA
    53818e0 View commit details
    Browse the repository at this point in the history

  3. doc: use TracyLayer::default where no customization of config occurs

    @nagisa
    nagisa committed Jan 27, 2024
    Configuration menu
    Copy the full SHA
    93fd449 View commit details
    Browse the repository at this point in the history

  4. config: perhaps drop DynamicConfig too? 

    In practice I have found that, whenever a library provides an ability to
configure through a trait generic and then provides a basic runtime
cofniguration convenience-type, the convenience type ends up being
dropped in favour of a manual implementation pretty quickly.

So it seems like a not-terrible-idea to just push users to the trait
immediately? And we don’t need to figure a good design for a
compile-time configuration type…

Might still go back on this decision, idk.
    @nagisa
    nagisa committed Jan 27, 2024
    Configuration menu
    Copy the full SHA
    fa4e1d0 View commit details
    Browse the repository at this point in the history

  5. pass in metadata for stack depth config

    @nagisa
    nagisa committed Jan 27, 2024
    Configuration menu
    Copy the full SHA
    a9e4c24 View commit details
    Browse the repository at this point in the history