WIP : Elektron Logging library #16
|
|
@ -9,16 +9,18 @@ import (
|
||||||
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!
|
|||||||
)
|
)
|
||||||
|
|
||||||
type ClsfnTaskDistrOverheadLogger struct {
|
type ClsfnTaskDistrOverheadLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
|
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 NewClsfnTaskDistrOverheadLogger(b *baseLogData, logType int, prefix string, logger *log.Logger) *ClsfnTaskDistrOverheadLogger {
|
func NewClsfnTaskDistrOverheadLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
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!
|
|||||||
|
logger *log.Logger, logDir *logDirectory) *ClsfnTaskDistrOverheadLogger {
|
||||||
|
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 := &ClsfnTaskDistrOverheadLogger{}
|
cLog := &ClsfnTaskDistrOverheadLogger{}
|
||||||
cLog.logType = logType
|
cLog.logType = logType
|
||||||
cLog.CreateLogFile(prefix)
|
cLog.logDir = logDir
|
||||||
|
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!
|
|||||||
cLog.next = nil
|
cLog.next = nil
|
||||||
cLog.baseLogData = b
|
cLog.baseLogData = b
|
||||||
cLog.logger = logger
|
cLog.logger = logger
|
||||||
|
cLog.createLogFile(prefix)
|
||||||
|
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!
|
|||||||
return cLog
|
return cLog
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -63,11 +65,11 @@ func (cLog ClsfnTaskDistrOverheadLogger) Logf(logType int, level log.Level, msgF
|
||||||
|
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 *ClsfnTaskDistrOverheadLogger) CreateLogFile(prefix string) {
|
func (cLog *ClsfnTaskDistrOverheadLogger) createLogFile(prefix string) {
|
||||||
|
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!
|
|||||||
|
|
||||||
if config.TaskDistrConfig.Enabled {
|
if config.TaskDistrConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.TaskDistrConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.TaskDistrConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := cLog.logDir.getDirName()
|
||||||
|
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!
|
|||||||
if dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
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!
|
|||||||
|
|
@ -1,24 +1,26 @@
|
||||||
|
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
|
|||||||
package elektronLogging
|
package elektronLogging
|
||||||
|
|
||||||
import (
|
import (
|
||||||
|
"fmt"
|
||||||
|
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
|
|||||||
|
log "github.com/sirupsen/logrus"
|
||||||
|
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
|
|||||||
"os"
|
"os"
|
||||||
"path/filepath"
|
"path/filepath"
|
||||||
"strings"
|
"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
|
|||||||
log "github.com/sirupsen/logrus"
|
|
||||||
|
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 {
|
type ConsoleLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
|
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(b *baseLogData, logType int, prefix string, logger *log.Logger) *ConsoleLogger {
|
func NewConsoleLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
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
|
|||||||
|
logger *log.Logger, logDir *logDirectory) *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{}
|
cLog := &ConsoleLogger{}
|
||||||
cLog.logType = logType
|
cLog.logType = logType
|
||||||
cLog.CreateLogFile(prefix)
|
cLog.logDir = logDir
|
||||||
|
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
|
|||||||
cLog.next = nil
|
cLog.next = nil
|
||||||
cLog.baseLogData = b
|
cLog.baseLogData = b
|
||||||
cLog.logger = logger
|
cLog.logger = logger
|
||||||
|
cLog.createLogFile(prefix)
|
||||||
|
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
|
|||||||
return cLog
|
return cLog
|
||||||
}
|
}
|
||||||
func (cLog ConsoleLogger) Log(logType int, level log.Level, message string) {
|
func (cLog ConsoleLogger) Log(logType int, level log.Level, message string) {
|
||||||
|
|
@ -58,11 +60,12 @@ func (cLog ConsoleLogger) Logf(logType int, level log.Level, msgFmtString string
|
||||||
|
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) CreateLogFile(prefix string) {
|
func (cLog *ConsoleLogger) createLogFile(prefix string) {
|
||||||
|
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
|
|||||||
// Create log file for the type if it is enabled.
|
// Create log file for the type if it is enabled.
|
||||||
if config.ConsoleConfig.Enabled {
|
if config.ConsoleConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.ConsoleConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.ConsoleConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := cLog.logDir.getDirName()
|
||||||
|
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
|
|||||||
|
fmt.Println(dirName)
|
||||||
|
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 dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
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
|
|||||||
|
|
@ -11,8 +11,7 @@ import (
|
||||||
|
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 config LoggerConfig
|
var config LoggerConfig
|
||||||
var formatter ElektronFormatter
|
var formatter ElektronFormatter
|
||||||
var ElektronLogger *LoggerImpl
|
var ElektronLogger *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`
|
|||||||
var logDir logDirectory
|
|
||||||
|
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, logConfigFilename string) {
|
func BuildLogger(prefix string, logConfigFilename string) {
|
||||||
|
|
||||||
|
|
@ -23,6 +22,7 @@ func BuildLogger(prefix string, logConfigFilename 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`
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`
|
|||||||
startTime := time.Now()
|
startTime := time.Now()
|
||||||
formatter.TimestampFormat = "2006-01-02 15:04:05"
|
formatter.TimestampFormat = "2006-01-02 15:04:05"
|
||||||
formattedStartTime := startTime.Format("20060102150405")
|
formattedStartTime := startTime.Format("20060102150405")
|
||||||
|
logDir := &logDirectory{}
|
||||||
|
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`
|
|||||||
logDir.createLogDir(prefix, startTime)
|
logDir.createLogDir(prefix, startTime)
|
||||||
|
|
||||||
// Instantiate the logrus instance.
|
// Instantiate the logrus instance.
|
||||||
|
|
@ -35,20 +35,20 @@ func BuildLogger(prefix string, logConfigFilename 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`
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 chain of loggers.
|
// Create a chain of loggers.
|
||||||
b := &baseLogData{data: log.Fields{}}
|
b := &baseLogData{data: log.Fields{}}
|
||||||
head := &LoggerImpl{baseLogData: b}
|
head := &loggerImpl{baseLogData: b}
|
||||||
|
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`
|
|||||||
cLog := NewConsoleLogger(b, CONSOLE, prefix, logger)
|
cLog := NewConsoleLogger(b, CONSOLE, prefix, logger, logDir)
|
||||||
|
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`
|
|||||||
pLog := NewPCPLogger(b, PCP, prefix, logger)
|
pLog := NewPCPLogger(b, PCP, prefix, logger, logDir)
|
||||||
|
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`
|
|||||||
schedTraceLog := NewSchedTraceLogger(b, SCHED_TRACE, prefix, logger)
|
schedTraceLog := NewSchedTraceLogger(b, SCHED_TRACE, prefix, logger, logDir)
|
||||||
|
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 := NewSchedPolicySwitchLogger(b, SPS, prefix, logger)
|
spsLog := NewSchedPolicySwitchLogger(b, SPS, prefix, logger, logDir)
|
||||||
|
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`
|
|||||||
schedWindowLog := NewSchedWindowLogger(b, SCHED_WINDOW, prefix, logger)
|
schedWindowLog := NewSchedWindowLogger(b, SCHED_WINDOW, prefix, logger, logDir)
|
||||||
|
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`
|
|||||||
tskDistLog := NewClsfnTaskDistrOverheadLogger(b, CLSFN_TASKDISTR_OVERHEAD, prefix, logger)
|
tskDistLog := NewClsfnTaskDistrOverheadLogger(b, CLSFN_TASKDISTR_OVERHEAD, prefix, logger, logDir)
|
||||||
|
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`
|
|||||||
|
|
||||||
head.SetNext(cLog)
|
head.setNext(cLog)
|
||||||
|
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`
|
|||||||
cLog.SetNext(pLog)
|
cLog.setNext(pLog)
|
||||||
|
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`
|
|||||||
pLog.SetNext(schedTraceLog)
|
pLog.setNext(schedTraceLog)
|
||||||
|
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`
|
|||||||
schedTraceLog.SetNext(spsLog)
|
schedTraceLog.setNext(spsLog)
|
||||||
|
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)
|
spsLog.setNext(schedWindowLog)
|
||||||
|
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`
|
|||||||
schedWindowLog.SetNext(tskDistLog)
|
schedWindowLog.setNext(tskDistLog)
|
||||||
|
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`
|
|||||||
|
|
||||||
ElektronLogger = head
|
ElektronLogger = 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`
|
|||||||
|
|
@ -5,51 +5,52 @@ import (
|
||||||
|
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
|
|||||||
"os"
|
"os"
|
||||||
)
|
)
|
||||||
|
|
||||||
type Logger interface {
|
type logInterface interface {
|
||||||
|
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
|
|||||||
SetNext(logType Logger)
|
setNext(logType logInterface)
|
||||||
|
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
|
|||||||
Log(logType int, level log.Level, message string)
|
Log(logType int, level log.Level, message string)
|
||||||
Logf(logType int, level log.Level, msgFmtString string, args ...interface{})
|
Logf(logType int, level log.Level, msgFmtString string, args ...interface{})
|
||||||
CreateLogFile(prefix string)
|
createLogFile(prefix string)
|
||||||
|
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
|
|||||||
}
|
}
|
||||||
type baseLogData struct {
|
type baseLogData struct {
|
||||||
data log.Fields
|
data log.Fields
|
||||||
}
|
}
|
||||||
type LoggerImpl struct {
|
type loggerImpl struct {
|
||||||
|
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
|
|||||||
*baseLogData
|
*baseLogData
|
||||||
logType int
|
logType int
|
||||||
allowOnConsole bool
|
allowOnConsole bool
|
||||||
logFile *os.File
|
logFile *os.File
|
||||||
next Logger
|
next logInterface
|
||||||
|
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
|
|||||||
logger *log.Logger
|
logger *log.Logger
|
||||||
|
logDir *logDirectory
|
||||||
|
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 (l *LoggerImpl) WithFields(logData log.Fields) *LoggerImpl {
|
func (l *loggerImpl) WithFields(logData log.Fields) *loggerImpl {
|
||||||
|
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.data = logData
|
l.data = logData
|
||||||
return l
|
return l
|
||||||
}
|
}
|
||||||
|
|
||||||
func (l *LoggerImpl) WithField(key string, value string) *LoggerImpl {
|
func (l *loggerImpl) WithField(key string, value string) *loggerImpl {
|
||||||
|
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.data[key] = value
|
l.data[key] = value
|
||||||
return l
|
return l
|
||||||
}
|
}
|
||||||
|
|
||||||
func (l *LoggerImpl) SetNext(logType Logger) {
|
func (l *loggerImpl) setNext(logType logInterface) {
|
||||||
|
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 = logType
|
l.next = logType
|
||||||
}
|
}
|
||||||
|
|
||||||
func (l LoggerImpl) Log(logType int, level log.Level, message string) {
|
func (l loggerImpl) Log(logType int, level log.Level, message string) {
|
||||||
|
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 l.next != nil {
|
if l.next != nil {
|
||||||
l.next.Log(logType, level, message)
|
l.next.Log(logType, level, message)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func (l LoggerImpl) Logf(logType int, level log.Level, msgFmtString string, args ...interface{}) {
|
func (l loggerImpl) Logf(logType int, level log.Level, msgFmtString string, args ...interface{}) {
|
||||||
|
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 l.next != nil {
|
if l.next != nil {
|
||||||
l.next.Logf(logType, level, msgFmtString, args...)
|
l.next.Logf(logType, level, msgFmtString, args...)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func (l *LoggerImpl) resetFields() {
|
func (l *loggerImpl) resetFields() {
|
||||||
|
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.data = nil
|
l.data = nil
|
||||||
l.data = log.Fields{}
|
l.data = 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
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
|
|||||||
|
|
@ -9,16 +9,18 @@ import (
|
||||||
|
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
|
|||||||
)
|
)
|
||||||
|
|
||||||
type PCPLogger struct {
|
type PCPLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
|
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(b *baseLogData, logType int, prefix string, logger *log.Logger) *PCPLogger {
|
func NewPCPLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
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
|
|||||||
|
logger *log.Logger, logDir *logDirectory) *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{}
|
pLog := &PCPLogger{}
|
||||||
pLog.logType = logType
|
pLog.logType = logType
|
||||||
pLog.CreateLogFile(prefix)
|
pLog.logDir = logDir
|
||||||
|
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
|
|||||||
pLog.next = nil
|
pLog.next = nil
|
||||||
pLog.baseLogData = b
|
pLog.baseLogData = b
|
||||||
pLog.logger = logger
|
pLog.logger = logger
|
||||||
|
pLog.createLogFile(prefix)
|
||||||
|
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
|
|||||||
return pLog
|
return pLog
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -63,10 +65,10 @@ func (pLog PCPLogger) Logf(logType int, level log.Level, msgFmtString string, ar
|
||||||
|
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) CreateLogFile(prefix string) {
|
func (pLog *PCPLogger) createLogFile(prefix string) {
|
||||||
|
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
|
|||||||
if config.PCPConfig.Enabled {
|
if config.PCPConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.PCPConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.PCPConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := pLog.logDir.getDirName()
|
||||||
|
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
|
|||||||
if dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
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
|
|||||||
|
|
@ -9,16 +9,18 @@ import (
|
||||||
)
|
)
|
||||||
|
|
||||||
type SchedPolicySwitchLogger struct {
|
type SchedPolicySwitchLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
}
|
}
|
||||||
|
|
||||||
func NewSchedPolicySwitchLogger(b *baseLogData, logType int, prefix string, logger *log.Logger) *SchedPolicySwitchLogger {
|
func NewSchedPolicySwitchLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
logger *log.Logger, logDir *logDirectory) *SchedPolicySwitchLogger {
|
||||||
sLog := &SchedPolicySwitchLogger{}
|
sLog := &SchedPolicySwitchLogger{}
|
||||||
sLog.logType = logType
|
sLog.logType = logType
|
||||||
sLog.CreateLogFile(prefix)
|
sLog.logDir = logDir
|
||||||
sLog.next = nil
|
sLog.next = nil
|
||||||
sLog.baseLogData = b
|
sLog.baseLogData = b
|
||||||
sLog.logger = logger
|
sLog.logger = logger
|
||||||
|
sLog.createLogFile(prefix)
|
||||||
return sLog
|
return sLog
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -63,10 +65,10 @@ func (sLog SchedPolicySwitchLogger) Logf(logType int, level log.Level, msgFmtStr
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func (sLog *SchedPolicySwitchLogger) CreateLogFile(prefix string) {
|
func (sLog *SchedPolicySwitchLogger) createLogFile(prefix string) {
|
||||||
if config.SPSConfig.Enabled {
|
if config.SPSConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.SPSConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.SPSConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := sLog.logDir.getDirName()
|
||||||
if dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
log.Fatal("Unable to create logFile: ", err)
|
||||||
|
|
|
||||||
|
|
@ -9,16 +9,18 @@ import (
|
||||||
)
|
)
|
||||||
|
|
||||||
type SchedTraceLogger struct {
|
type SchedTraceLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
}
|
}
|
||||||
|
|
||||||
func NewSchedTraceLogger(b *baseLogData, logType int, prefix string, logger *log.Logger) *SchedTraceLogger {
|
func NewSchedTraceLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
logger *log.Logger, logDir *logDirectory) *SchedTraceLogger {
|
||||||
sLog := &SchedTraceLogger{}
|
sLog := &SchedTraceLogger{}
|
||||||
sLog.logType = logType
|
sLog.logType = logType
|
||||||
sLog.CreateLogFile(prefix)
|
sLog.logDir = logDir
|
||||||
sLog.next = nil
|
sLog.next = nil
|
||||||
sLog.baseLogData = b
|
sLog.baseLogData = b
|
||||||
sLog.logger = logger
|
sLog.logger = logger
|
||||||
|
sLog.createLogFile(prefix)
|
||||||
return sLog
|
return sLog
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -63,10 +65,10 @@ func (sLog SchedTraceLogger) Logf(logType int, level log.Level, msgFmtString str
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func (sLog *SchedTraceLogger) CreateLogFile(prefix string) {
|
func (sLog *SchedTraceLogger) createLogFile(prefix string) {
|
||||||
if config.SchedTraceConfig.Enabled {
|
if config.SchedTraceConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.SchedTraceConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.SchedTraceConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := sLog.logDir.getDirName()
|
||||||
if dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
log.Fatal("Unable to create logFile: ", err)
|
||||||
|
|
|
||||||
|
|
@ -9,16 +9,18 @@ import (
|
||||||
)
|
)
|
||||||
|
|
||||||
type SchedWindowLogger struct {
|
type SchedWindowLogger struct {
|
||||||
LoggerImpl
|
loggerImpl
|
||||||
}
|
}
|
||||||
|
|
||||||
func NewSchedWindowLogger(b *baseLogData, logType int, prefix string, logger *log.Logger) *SchedWindowLogger {
|
func NewSchedWindowLogger(b *baseLogData, logType int, prefix string,
|
||||||
|
logger *log.Logger, logDir *logDirectory) *SchedWindowLogger {
|
||||||
sLog := &SchedWindowLogger{}
|
sLog := &SchedWindowLogger{}
|
||||||
sLog.logType = logType
|
sLog.logType = logType
|
||||||
sLog.CreateLogFile(prefix)
|
sLog.logDir = logDir
|
||||||
sLog.next = nil
|
sLog.next = nil
|
||||||
sLog.baseLogData = b
|
sLog.baseLogData = b
|
||||||
sLog.logger = logger
|
sLog.logger = logger
|
||||||
|
sLog.createLogFile(prefix)
|
||||||
return sLog
|
return sLog
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -63,10 +65,10 @@ func (sLog SchedWindowLogger) Logf(logType int, level log.Level, msgFmtString st
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
func (sLog *SchedWindowLogger) CreateLogFile(prefix string) {
|
func (sLog *SchedWindowLogger) createLogFile(prefix string) {
|
||||||
if config.SchedWindowConfig.Enabled {
|
if config.SchedWindowConfig.Enabled {
|
||||||
filename := strings.Join([]string{prefix, config.SchedWindowConfig.FilenameExtension}, "")
|
filename := strings.Join([]string{prefix, config.SchedWindowConfig.FilenameExtension}, "")
|
||||||
dirName := logDir.getDirName()
|
dirName := sLog.logDir.getDirName()
|
||||||
if dirName != "" {
|
if dirName != "" {
|
||||||
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
if logFile, err := os.Create(filepath.Join(dirName, filename)); err != nil {
|
||||||
log.Fatal("Unable to create logFile: ", err)
|
log.Fatal("Unable to create logFile: ", err)
|
||||||
|
|
|
||||||
Use struct literals instead of new as it's more descriptive:
&ClsfnTaskDistOverheadLogger{}Where is log dir coming from? Shouldn't be a global