WIP : Elektron Logging library #16
|
|
@ -2,7 +2,6 @@ package elektronLogging
|
|||
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"fmt"
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
"github.com/fatih/color"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"strings"
|
||||
|
|
@ -37,14 +36,12 @@ func (f ElektronFormatter) Format(entry *log.Entry) ([]byte, error) {
|
|||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
|
||||
levelColor := f.getColor(entry)
|
||||
level := levelColor.Sprintf("[%s]:", strings.ToUpper(entry.Level.String()))
|
||||
message := fmt.Sprintf("%s %s ", level, entry.Time.Format(f.TimestampFormat))
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
if entry.Message != "" {
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
message = fmt.Sprintf("%s %s %s ", level, entry.Time.Format(f.TimestampFormat), entry.Message)
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
}
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
message := strings.Join([]string{level, entry.Time.Format(f.TimestampFormat), entry.Message, " "}, " ")
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
var formattedFields []string
|
||||
for key, value := range entry.Data {
|
||||
formattedFields = append(formattedFields,
|
||||
strings.Join([]string{key, fmt.Sprintf("%s", value)}, "="))
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
strings.Join([]string{key, value.(string)}, "="))
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
}
|
||||
|
||||
b.WriteString(message)
|
||||
|
|
|
|||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
)
|
||||
|
||||
type ClsfnTaskDistOverheadLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type ClsfnTaskDistOverheadLogger struct {
|
|||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
}
|
||||
|
||||
func NewClsfnTaskDistOverheadLogger(logType int, prefix string) *ClsfnTaskDistOverheadLogger {
|
||||
cLog := new(ClsfnTaskDistOverheadLogger)
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
cLog := &ClsfnTaskDistOverheadLogger{}
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
cLog.Type = logType
|
||||
cLog.SetLogFile(prefix)
|
||||
return cLog
|
||||
|
|
@ -36,9 +37,9 @@ func (cLog *ClsfnTaskDistOverheadLogger) Log(logType int, level log.Level, logDa
|
|||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
|
||||
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
|
||||
|
||||
tskDistLogPrefix := prefix + config.TaskDistConfig.FilenameExtension
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
tskDistLogPrefix := strings.Join([]string{prefix, config.TaskDistConfig.FilenameExtension}, "")
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
if logDir != "" {
|
||||
tskDistLogPrefix = logDir + "/" + tskDistLogPrefix
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
tskDistLogPrefix = strings.Join([]string{logDir, tskDistLogPrefix}, "/")
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
}
|
||||
if logFile, err := os.Create(tskDistLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
)
|
||||
|
||||
type ConsoleLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type ConsoleLogger struct {
|
|||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
}
|
||||
|
||||
func NewConsoleLogger(logType int, prefix string) *ConsoleLogger {
|
||||
cLog := new(ConsoleLogger)
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
cLog := &ConsoleLogger{}
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
cLog.Type = logType
|
||||
cLog.SetLogFile(prefix)
|
||||
return cLog
|
||||
|
|
@ -18,7 +19,6 @@ func NewConsoleLogger(logType int, prefix string) *ConsoleLogger {
|
|||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
func (cLog *ConsoleLogger) Log(logType int, level log.Level, logData log.Fields, message string) {
|
||||
if logType <= cLog.Type {
|
||||
|
||||
//logFields := cloneFields(logData)
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
logger.SetLevel(level)
|
||||
|
||||
logger.SetOutput(os.Stdout)
|
||||
|
|
@ -34,9 +34,9 @@ func (cLog *ConsoleLogger) Log(logType int, level log.Level, logData log.Fields,
|
|||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
|
||||
func (cLog *ConsoleLogger) SetLogFile(prefix string) {
|
||||
|
||||
consoleLogPrefix := prefix + config.ConsoleConfig.FilenameExtension
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
consoleLogPrefix := strings.Join([]string{prefix, config.ConsoleConfig.FilenameExtension}, "")
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
if logDir != "" {
|
||||
consoleLogPrefix = logDir + "/" + consoleLogPrefix
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
consoleLogPrefix = strings.Join([]string{logDir, consoleLogPrefix}, "/")
|
||||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
}
|
||||
if logFile, err := os.Create(consoleLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
I see why you are directly assigning I see why you are directly assigning `true`. However, to allow disabling console logs to stdout retrofit this to `cLog.AllowOnConsole = config.ConsoleConfig.AllowOnConsole`.
Why the pointer receiver? Technically, this function should not lead to change of state. Why the pointer receiver? Technically, this function should not lead to change of state.
Sure Sure
Yeah, thats right. I will change it Yeah, thats right. I will change it
|
||||
|
|
@ -4,6 +4,7 @@ import (
|
|||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logrus "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strconv"
|
||||
"strings"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
"time"
|
||||
)
|
||||
|
||||
|
|
@ -16,18 +17,13 @@ func GetLogDir(startTime time.Time, prefix string) {
|
|||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
}
|
||||
|
||||
func createLogDir(prefix string, startTime time.Time) string {
|
||||
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
// Creating directory to store all logs for this run
|
||||
logDirName := "./" + prefix + strconv.Itoa(startTime.Year())
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += "-"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += startTime.Month().String()
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += "-"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += strconv.Itoa(startTime.Day())
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += "_"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += strconv.Itoa(startTime.Hour())
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += "-"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += strconv.Itoa(startTime.Minute())
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += "-"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName += strconv.Itoa(startTime.Second())
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName := strings.Join([]string{"./", prefix, strconv.Itoa(startTime.Year())}, "")
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName = strings.Join([]string{logDirName, startTime.Month().String(), strconv.Itoa(startTime.Day())}, "-")
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName = strings.Join([]string{logDirName, strconv.Itoa(startTime.Hour())}, "_")
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
logDirName = strings.Join([]string{logDirName, strconv.Itoa(startTime.Minute()), strconv.Itoa(startTime.Second())}, "-")
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
if _, err := os.Stat(logDirName); os.IsNotExist(err) {
|
||||
os.Mkdir(logDirName, 0755)
|
||||
} else {
|
||||
|
|
|
|||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
|
|
@ -1,18 +1,18 @@
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
log "github.com/sirupsen/logrus"
|
||||
. "github.com/spdfg/elektron/elektronLogging/types"
|
||||
"strconv"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
"strings"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
"time"
|
||||
)
|
||||
|
||||
var config LoggerConfig
|
||||
var logger *log.Logger
|
||||
var formatter ElektronFormatter
|
||||
var ElektronLog *LoggerImpl
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
||||
func BuildLogger() *LoggerImpl {
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
func BuildLogger(prefix string) {
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
||||
// read configuration from yaml
|
||||
config.GetConfig()
|
||||
|
|
@ -20,17 +20,17 @@ func BuildLogger() *LoggerImpl {
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
// create the log directory
|
||||
startTime := time.Now()
|
||||
formatter.TimestampFormat = "2006-01-02 15:04:05"
|
||||
formattedStartTime := startTime.Format("20060102150405")
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
GetLogDir(startTime, "_")
|
||||
|
||||
prefix := fmt.Sprintf("_%d%d%s%s%s%s", startTime.Year(), startTime.Month(), strconv.Itoa(startTime.Day()),
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
strconv.Itoa(startTime.Hour()), strconv.Itoa(startTime.Minute()), strconv.Itoa(startTime.Second()))
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
prefix = strings.Join([]string{prefix, formattedStartTime}, "_")
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
||||
//create a single logrus instance and set its formatter to ElektronFormatter
|
||||
logger = log.New()
|
||||
logger.SetFormatter(&formatter)
|
||||
|
||||
// create a chain of loggers
|
||||
head := new(LoggerImpl)
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
head := &LoggerImpl{}
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
cLog := NewConsoleLogger(CONSOLE, prefix)
|
||||
pLog := NewPcpLogger(PCP, prefix)
|
||||
schedTraceLog := NewSchedTraceLogger(SCHED_TRACE, prefix)
|
||||
|
|
@ -45,7 +45,5 @@ func BuildLogger() *LoggerImpl {
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
spsLog.SetNext(schedWindowLog)
|
||||
schedWindowLog.SetNext(tskDistLog)
|
||||
|
||||
return head
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
ElektronLog = head
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
}
|
||||
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
var ElektronLog = BuildLogger()
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
|
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
|
@ -1,9 +1,8 @@
|
|||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
//data "github.com/spdfg/elektron/elektronLogging/data"
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
)
|
||||
|
||||
type Logger interface {
|
||||
|
|
@ -27,11 +26,3 @@ func (l *LoggerImpl) Log(logType int, level log.Level, logData log.Fields, messa
|
|||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
l.next.Log(logType, level, logData, message)
|
||||
}
|
||||
}
|
||||
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
/*func cloneFields(logData data.LogData) log.Fields {
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
var newMap = make(log.Fields)
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
for k,v := range logData {
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
newMap[k] = v
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
}
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
return newMap
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
}*/
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
|
|
|
|||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
)
|
||||
|
||||
type PcpLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type PcpLogger struct {
|
|||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
}
|
||||
|
||||
func NewPcpLogger(logType int, prefix string) *PcpLogger {
|
||||
pLog := new(PcpLogger)
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
pLog := &PcpLogger{}
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
pLog.Type = logType
|
||||
pLog.SetLogFile(prefix)
|
||||
return pLog
|
||||
|
|
@ -36,9 +37,9 @@ func (pLog *PcpLogger) Log(logType int, level log.Level, logData log.Fields, mes
|
|||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
|
||||
func (plog *PcpLogger) SetLogFile(prefix string) {
|
||||
|
||||
pcpLogPrefix := prefix + config.PCPConfig.FilenameExtension
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
pcpLogPrefix := strings.Join([]string{prefix, config.PCPConfig.FilenameExtension}, "")
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
if logDir != "" {
|
||||
pcpLogPrefix = logDir + "/" + pcpLogPrefix
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
pcpLogPrefix = strings.Join([]string{logDir, pcpLogPrefix}, "/")
|
||||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
}
|
||||
if logFile, err := os.Create(pcpLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
Refactor to Refactor to `PCPLogger`.
Why not just do this? Where Why not just do this?
```go
return &PCPLogger{
LoggerIml{
Type: logType
LogFile: CreateLogFile(prefix),
}
}
```
Where `func CreateLogFile(prefix string) string` replaces `func SetLogFile(prefix string)`.
Done Done
|
||||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
)
|
||||
|
||||
type SchedPolicySwitchLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type SchedPolicySwitchLogger struct {
|
|||
}
|
||||
|
||||
func NewSchedPolicySwitchLogger(logType int, prefix string) *SchedPolicySwitchLogger {
|
||||
sLog := new(SchedPolicySwitchLogger)
|
||||
sLog := &SchedPolicySwitchLogger{}
|
||||
sLog.Type = logType
|
||||
sLog.SetLogFile(prefix)
|
||||
return sLog
|
||||
|
|
@ -36,9 +37,9 @@ func (sLog *SchedPolicySwitchLogger) Log(logType int, level log.Level, logData l
|
|||
|
||||
func (sLog *SchedPolicySwitchLogger) SetLogFile(prefix string) {
|
||||
|
||||
spsLogPrefix := prefix + config.SPSConfig.FilenameExtension
|
||||
spsLogPrefix := strings.Join([]string{prefix, config.SPSConfig.FilenameExtension}, "")
|
||||
if logDir != "" {
|
||||
spsLogPrefix = logDir + "/" + spsLogPrefix
|
||||
spsLogPrefix = strings.Join([]string{logDir, spsLogPrefix}, "/")
|
||||
}
|
||||
if logFile, err := os.Create(spsLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
)
|
||||
|
||||
type SchedTraceLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type SchedTraceLogger struct {
|
|||
}
|
||||
|
||||
func NewSchedTraceLogger(logType int, prefix string) *SchedTraceLogger {
|
||||
sLog := new(SchedTraceLogger)
|
||||
sLog := &SchedTraceLogger{}
|
||||
sLog.Type = logType
|
||||
sLog.SetLogFile(prefix)
|
||||
return sLog
|
||||
|
|
@ -36,9 +37,9 @@ func (sLog *SchedTraceLogger) Log(logType int, level log.Level, logData log.Fiel
|
|||
|
||||
func (sLog *SchedTraceLogger) SetLogFile(prefix string) {
|
||||
|
||||
schedTraceLogPrefix := prefix + config.SchedTraceConfig.FilenameExtension
|
||||
schedTraceLogPrefix := strings.Join([]string{prefix, config.SchedTraceConfig.FilenameExtension}, "")
|
||||
if logDir != "" {
|
||||
schedTraceLogPrefix = logDir + "/" + schedTraceLogPrefix
|
||||
schedTraceLogPrefix = strings.Join([]string{logDir, schedTraceLogPrefix}, "/")
|
||||
}
|
||||
if logFile, err := os.Create(schedTraceLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ package elektronLogging
|
|||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
"strings"
|
||||
)
|
||||
|
||||
type SchedWindowLogger struct {
|
||||
|
|
@ -10,7 +11,7 @@ type SchedWindowLogger struct {
|
|||
}
|
||||
|
||||
func NewSchedWindowLogger(logType int, prefix string) *SchedWindowLogger {
|
||||
sLog := new(SchedWindowLogger)
|
||||
sLog := &SchedWindowLogger{}
|
||||
sLog.Type = logType
|
||||
sLog.SetLogFile(prefix)
|
||||
return sLog
|
||||
|
|
@ -20,6 +21,7 @@ func (sLog *SchedWindowLogger) Log(logType int, level log.Level, logData log.Fie
|
|||
if sLog.Type == logType {
|
||||
|
||||
logger.SetLevel(level)
|
||||
|
||||
if sLog.AllowOnConsole {
|
||||
logger.SetOutput(os.Stdout)
|
||||
logger.WithFields(logData).Println(message)
|
||||
|
|
@ -35,9 +37,9 @@ func (sLog *SchedWindowLogger) Log(logType int, level log.Level, logData log.Fie
|
|||
|
||||
func (sLog *SchedWindowLogger) SetLogFile(prefix string) {
|
||||
|
||||
schedWindowLogPrefix := prefix + config.SchedWindowConfig.FilenameExtension
|
||||
schedWindowLogPrefix := strings.Join([]string{prefix, config.SchedWindowConfig.FilenameExtension}, "")
|
||||
if logDir != "" {
|
||||
schedWindowLogPrefix = logDir + "/" + schedWindowLogPrefix
|
||||
schedWindowLogPrefix = strings.Join([]string{logDir, schedWindowLogPrefix}, "/")
|
||||
}
|
||||
if logFile, err := os.Create(schedWindowLogPrefix); err != nil {
|
||||
log.Fatal("Unable to create logFile: ", err)
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
package elektronLogging
|
||||
|
||||
const (
|
||||
ERROR = iota
|
||||
WARNING = iota
|
||||
GENERAL = iota
|
||||
SUCCESS = iota
|
||||
CONSOLE = iota
|
||||
PCP = iota
|
||||
SCHED_TRACE = iota
|
||||
SPS = iota
|
||||
SCHED_WINDOW = iota
|
||||
CLSFN_TASKDIST_OVERHEAD = iota
|
||||
ERROR = iota
|
||||
WARNING
|
||||
GENERAL
|
||||
SUCCESS
|
||||
CONSOLE
|
||||
PCP
|
||||
SCHED_TRACE
|
||||
SPS
|
||||
SCHED_WINDOW
|
||||
CLSFN_TASKDIST_OVERHEAD
|
||||
)
|
||||
|
|
|
|||
18
scheduler.go
|
|
@ -21,10 +21,6 @@ package main // import github.com/spdfg/elektron
|
|||
import (
|
||||
"flag"
|
||||
"fmt"
|
||||
"os"
|
||||
"os/signal"
|
||||
"time"
|
||||
|
||||
"github.com/golang/protobuf/proto"
|
||||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
sched "github.com/mesos/mesos-go/api/v0/scheduler"
|
||||
|
|
@ -35,6 +31,10 @@ import (
|
|||
"github.com/spdfg/elektron/pcp"
|
||||
"github.com/spdfg/elektron/powerCap"
|
||||
"github.com/spdfg/elektron/schedulers"
|
||||
"os"
|
||||
"os/signal"
|
||||
"strings"
|
||||
"time"
|
||||
)
|
||||
|
||||
var master = flag.String("master", "", "Location of leading Mesos master -- <mesos-master>:<port>")
|
||||
|
|
@ -116,11 +116,6 @@ func main() {
|
|||
pcpLog := make(chan struct{})
|
||||
recordPCP := false
|
||||
|
||||
// Logging channels.
|
||||
// These channels are used by the framework to log messages.
|
||||
// The channels are used to send the type of log message and the message string.
|
||||
//schedOptions = append(schedOptions, schedulers.WithLoggingChannels(logMType, logMsg))
|
||||
|
||||
// Shutdown indicator channels.
|
||||
// These channels are used to notify,
|
||||
// 1. scheduling is complete.
|
||||
|
|
@ -225,9 +220,10 @@ func main() {
|
|||
}
|
||||
|
||||
// Checking if prefix contains any special characters.
|
||||
/*if strings.Contains(*pcplogPrefix, "/") {
|
||||
if strings.Contains(*pcplogPrefix, "/") {
|
||||
log.Fatal("log file prefix should not contain '/'.")
|
||||
}*/
|
||||
}
|
||||
elektronLogging.BuildLogger(*pcplogPrefix)
|
||||
|
||||
// Starting PCP logging.
|
||||
if noPowercap {
|
||||
|
|
|
|||
Formatting
Formatting
Use strings.join instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.