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

Enhancement for logs #30000

Closed
wants to merge 3 commits into from
Closed

Enhancement for logs #30000

wants to merge 3 commits into from

Conversation

AmirDoreh
Copy link

This pr offers:

  • some comments enhancements
  • refactoring codes
  • initializing siteCache to prevent nil map access.

siteCache to prevent nil map access
comments enhancements
enhance comments
@@ -173,8 +173,8 @@ func (l *logger) Write(level slog.Level, msg string, attrs ...any) {
l.inner.Handler().Handle(context.Background(), r)
}

func (l *logger) Log(level slog.Level, msg string, attrs ...any) {
l.Write(level, msg, attrs...)
func (l *logger) Log(level slog.Level, msg string, ctx ...interface{}) {
Copy link
Member

Choose a reason for hiding this comment

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

Why do you prefer interface to any here?


fs := runtime.CallersFrames([]uintptr{r.PC})
frame, _ := fs.Next()

for _, rule := range h.patterns {
if rule.pattern.MatchString(fmt.Sprintf("+%s", frame.File)) {
h.siteCache[r.PC], lvl, ok = rule.level, rule.level, true
break
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't this change the logic by only matching on the first occurrence instead of every occurrence?

@@ -184,20 +186,21 @@ func (h *GlogHandler) Handle(_ context.Context, r slog.Record) error {
// If we didn't cache the callsite yet, calculate it
if !ok {
h.lock.Lock()
defer h.lock.Unlock()
Copy link
Member

Choose a reason for hiding this comment

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

Afaict this will lock the handler even for the h.origin.Handle call in line 206 (203 in original) which means we hold the lock longer than we need to

}
buf.WriteString(color)
buf.Write(appendEscapeString(buf.AvailableBuffer(), attr.Key))
buf.WriteString("\x1b[0m=")
Copy link
Member

Choose a reason for hiding this comment

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

Pretty sure that this is wrong, previously we wrote = when color was "", now its "\x1b[0m="

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

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

I don't really see a theme here, looks a bit like a few random changes here and there in the log package. But none of it really meaningful. Am I missing something?

}
b.WriteString(color)
b.WriteString(LevelAlignedString(r.Level))
b.WriteString("\x1b[0m")
Copy link
Contributor

Choose a reason for hiding this comment

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

This should only be written if we're using terminal colors

fieldPadding map[string]int

buf []byte
mu sync.Mutex // Mutex for thread safety
Copy link
Contributor

Choose a reason for hiding this comment

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

"Mutex for thread safety" is a moot description.
The fact that it's a mutex is already given, and mutexes are used for "thread safety", or rather, to handle mutually exclusive accesses in a multi-threaded context.

If you want to put a meaningful description, you should instead say something like "mu is used to prevent multu-threaded access on the buf field" or something like that, which describes specifically what fields the mu guards.

Comment on lines +129 to +130
// compilePattern converts a vmodule pattern to a regular expression string.
func compilePattern(pattern string) string {
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the benefit of moving this out?

@@ -168,7 +170,7 @@ func (h *GlogHandler) WithGroup(name string) slog.Handler {
panic("not implemented")
}

// Log implements Handler.Log, filtering a log record through the global, local
Copy link
Contributor

Choose a reason for hiding this comment

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

This has been fixed in #29907 please revert this changes

@holiman
Copy link
Contributor

holiman commented Jun 17, 2024

In the past many months we have had a lot of issues with people opening PRs that are - for the most part - not useful. These include typo fixes, performance optimisations in non-hot code paths, variable renames, error message tweaks, etc. Whilst these PRs aren't unilaterally bad or worthless, most people are not opening them to make our codebase better, rather they are opening to farm commits for airdrops.

From our perspective, these commits often take a non-negligible effort to review and merge, because they keep touching sensitive code, that we need to be extra careful to understand. Even trivial fixes require attention and keep distracting us from focusing on developing and maintaining Geth.

We've decided to be more agressive in rejecting outside contributions that do not make a meaningful improvement:

  • Issues flagged by linters or third party tools should be discussed on a GitHub issue first to see if it makes sense to fix them, and if so, the correct way is to add a new linter step to our CIs so that issues are caught when being added, not kept being fixed in perpetuity.
  • Optimisations (especially when they lower code readability) should be done only in hot paths where performance actually matters, and even in those cases, there should be some benchmarks (ideally from the existing ones) highlighting their benefit.
  • As for typos, variable renames, error rewordings and such, should be opened as part of larger meaningful changes, not as tiny standalone PRs.

We appreciate the enthusiasm and effort of opening a PR against Geth, but due to the significant abuse against our time, we'll be closing PRs of the above type for the foreseeable future. We apologise if someone's genuine effort gets caught up in this agressive stance.

@holiman holiman closed this Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants