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

[epilogue] Backend refactoring and interface fixes #7548

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

Daniel1464
Copy link
Contributor

@Daniel1464 Daniel1464 commented Dec 14, 2024

This PR fixes a couple of things:

  1. Interface inheritance is fixed. Previously, interfaces without the @Logged moniker would not be logged, regardless if any implementing members had an @Logged field or method. This fixes that.
  2. NTEpilogueBackend was renamed to NTBackend for clarity; in addition, a no-args constructor(that uses the default NT instance) was added. Finally, the "disableWhen" method for NTBackend was added to allow for new NTBackend().disableWhen(DriverStation::isFmsAttached)
  3. FileBackend gains a no-args constructor hat uses the default DataLogManager.getLog() instance.

@Daniel1464 Daniel1464 requested a review from a team as a code owner December 14, 2024 14:52
@github-actions github-actions bot added the component: epilogue Annotation-based logging library label Dec 14, 2024
@Daniel1464 Daniel1464 changed the title [Epilogue] Backend refactoring and interface fixes [epilogue] Backend refactoring and interface fixes Dec 14, 2024
@@ -143,12 +143,19 @@ private Set<TypeElement> getLoggedTypes(RoundEnvironment roundEnv) {
annotatedElements.stream()
.filter(e -> e instanceof TypeElement)
.map(e -> (TypeElement) e),
// 2. All type elements containing a field or method with the @Logged annotation
// 2. All type elements containing a field or method with the @Logged annotation,
// or interfaces which have an implementing class with an @Logged annotation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be better to change methodsToLog in LoggerGenerator to look at superclass and interface methods. This has the side effect of making a plain interface loggable if it happens to have a loggable implementation, which is completely invisible to anyone looking at the interface declaration.

Copy link
Contributor Author

@Daniel1464 Daniel1464 Dec 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was the intention. Currently, the "logger file" generated by epilogue for said interface is blank(so there's no side effects). The idea is that if you put @Logged on a IO impl but not the IO, then fields on said impl will still be logged(while not logging any default members of the IO interface)

Comment on lines 120 to 122
interface ABC {
default double a() { return 2.0; }
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be loggable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to still generate a logger for the interface ABC because it has classes that inherit from it(that can be logged)

* @param disabledSupplier the disable condition for NT logging
* @return a new NTBackend
*/
public NTBackend disableWhen(BooleanSupplier disabledSupplier) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this better than just changing the backend on the fly?

if (condition()) {
  Epilogue.configure(config -> {
    config.backend = new NullBackend();
  });
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more succint, and prevents you from having to cache different kinds of backends yourself.
For instance, if you only want NT logging enabled when fms is not attached, you would have to cache a file only backend, a file and nt backend, and use an addPeriodic call.

In addition, the configure() method accepts a lambda, and if it is called every loop, it will spawn a new object every loop as well

Copy link
Member

@SamCarlberg SamCarlberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The NTBackend rename and FileBackend default constructor changes are good, and should be merged. The disabling feature and automagic loggable interfaces changes need more discussion/iterations, and would be better to split into separate PRs to avoid blocking the straightforward backend updates

@Daniel1464
Copy link
Contributor Author

/format

@Daniel1464
Copy link
Contributor Author

@SamCarlberg I just made 2 changes:

  1. The NetworkTableInstance and DataLog constructors for the backends package-private because they aren't really necessary anymore
  2. FileBackend's constructor now accepts a boolean on whether to enable NT capture or not. I'm still kinda dubious on this, but I think it might be better than a no-args constructor since it exposes the side effect of DataLogManager.getLog() and DataLogManager.start() to the user(which is capturing NT data). I want to hear your thoughts on this though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: epilogue Annotation-based logging library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants