WIP : Elektron Logging library #16
|
|
@ -25,9 +25,9 @@ import (
|
|||
Okay. Done Okay. Done
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages. I would alias this to _elekLog_ as you seem to be using that prefix when aliasing imports of sub-packages.
Okay. Done Okay. Done
|
||||
|
||||
"github.com/mash/gokmeans"
|
||||
"github.com/montanaflynn/stats"
|
||||
log "github.com/sirupsen/logrus"
|
||||
|
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages. I would alias this to _elekLog_ as you seem to be using that prefix when aliasing imports of sub-packages.
Okay. Done Okay. Done
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
|
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages. I would alias this to _elekLog_ as you seem to be using that prefix when aliasing imports of sub-packages.
Okay. Done Okay. Done
|
||||
)
|
||||
|
||||
// Information about a cluster of tasks.
|
||||
|
|
|
|||
|
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages. I would alias this to _elekLog_ as you seem to be using that prefix when aliasing imports of sub-packages.
Okay. Done Okay. Done
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages. I would alias this to _elekLog_ as you seem to be using that prefix when aliasing imports of sub-packages.
Okay. Done Okay. Done
|
||||
|
|
@ -3,9 +3,9 @@ package elektronLogging
|
|||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
import (
|
||||
"bytes"
|
||||
"fmt"
|
||||
"strings"
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
"github.com/fatih/color"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"strings"
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
)
|
||||
|
||||
type ElektronFormatter struct {
|
||||
|
|
@ -47,7 +47,6 @@ func (f ElektronFormatter) Format(entry *log.Entry) ([]byte, error) {
|
|||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
strings.Join([]string{key, fmt.Sprintf("%s", value)}, "="))
|
||||
}
|
||||
|
||||
|
||||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
b.WriteString(message)
|
||||
b.WriteString(strings.Join(formattedFields, ", "))
|
||||
b.WriteByte('\n')
|
||||
|
|
|
|||
|
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
Formatting Formatting
Formatting Formatting
Use strings.join instead. You should create the slice and append the message if necessary. Use [strings.join](https://golang.org/pkg/strings/#Join) instead. You should create the slice and append the message if necessary.
This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf. This seems really inefficient. Wouldn't value already have to be a string for this to succeed? In which case, I don't think we gain anything here by suing a sprintf.
Okay. Sure Okay. Sure
value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : value is not a string here, it is of type interface{}. But to avoid using sprintf, would it be fine to use type assertion? For eg : `value.(string) `
Done Done
Done Done
Line 43 and 44 can fit in one line. We currently do not have any style linting setup. Line 43 and 44 can fit in one line. We currently do not have any style linting setup.
Peeked at how logrus serializes values and seems like fmt.Sprint is used if type assertion fails. Peeked at how [logrus](https://github.com/sirupsen/logrus/blob/67a7fdcf741f4d5cee82cb9800994ccfd4393ad0/text_formatter.go#L315) serializes values and seems like fmt.Sprint is used if type assertion fails.
ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it. ahh alright, I thought it was a string coming in. Alright, if it's been sanity checked then i'm good with it.
Okay Okay
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
|
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!
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
|
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!
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
|
Use struct literals instead of new as it's more descriptive: Use struct literals instead of new as it's more descriptive:
`&ClsfnTaskDistOverheadLogger{}`
Where is log dir coming from? Shouldn't be a global Where is log dir coming from? Shouldn't be a global
Okay, will do the changes Okay, will do the changes
It is defined in It is defined in `createLogDir.go`. Since all these files belong to same package, I accessed it in this way.
I think it will be better if it is encapsulated. I think it will be better if it is encapsulated.
Something like
```go
type logDir struct {
name string
// other fields if necessary.
}
```
Maybe refactor to Maybe refactor to `ClsfnTaskDistrOverheadLogger` so that it is clear that we are intending "Distribution" and now "Distance"?
You should use filepath.Join(...) to keep it generic. You should use [filepath.Join(...)](https://golang.org/src/path/filepath/path.go?s=5893:5925#L199) to keep it generic.
You can possible rewrite this function to something like the one shown below. You can possible rewrite this function to something like the one shown below.
```go
func (cLog *ClsfnTaskDistOverheadLogger) SetLogFile(prefix string) {
filename := prefix + config.TaskDistConfig.FilenameExtension
if logDir != "" {
if logFile, err := os.Create(filepath.Join(logDir, filename)); err != nil {
log.Fatal("Unable to create logFile: ", err)
} else {
cLog.LogFileName = logFile
cLog.AllowOnConsole = config.TaskDistConfig.AllowOnConsole
}
}
}
```
Done Done
Done Done
Okay. Sure Okay. Sure
Done Done
looks good now thanks! looks good now thanks!
|
||||
)
|
||||
|
||||
type ClsfnTaskDistOverheadLogger struct {
|
||||
|
|
|
|||
|
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,8 +1,8 @@
|
|||
|
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
|
||||
|
||||
import (
|
||||
"os"
|
||||
|
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"
|
||||
"os"
|
||||
|
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 {
|
||||
|
|
|
|||
|
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
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
logrus "github.com/sirupsen/logrus"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
"os"
|
||||
"strconv"
|
||||
"time"
|
||||
logrus "github.com/sirupsen/logrus"
|
||||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
)
|
||||
|
||||
var logDir string
|
||||
|
|
|
|||
|
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
Why not use Why not use `string.join([]string{...}, "")` ?
Yeah, thats right Yeah, thats right
Extend the comment to show how the format of the log directory name is going to look. Extend the comment to show how the format of the log directory name is going to look.
Keep the alias for logrus import consistent. So, refactor this to "log". Keep the alias for logrus import consistent. So, refactor this to "log".
Done Done
Done Done
|
||||
|
|
@ -1,11 +1,11 @@
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
"time"
|
||||
|
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`
|
||||
"fmt"
|
||||
"strconv"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
. "github.com/spdfg/elektron/elektronLogging/types"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
log "github.com/sirupsen/logrus"
|
||||
. "github.com/spdfg/elektron/elektronLogging/types"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
"strconv"
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
"time"
|
||||
|
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
|
||||
|
|
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
|
@ -1,13 +1,13 @@
|
|||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
package elektronLogging
|
||||
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
import (
|
||||
"gopkg.in/yaml.v2"
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
"io/ioutil"
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
log "github.com/sirupsen/logrus"
|
||||
elekEnv "github.com/spdfg/elektron/environment"
|
||||
"gopkg.in/yaml.v2"
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
"io/ioutil"
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
)
|
||||
|
||||
type LoggerConfig struct {
|
||||
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
SchedTraceConfig struct {
|
||||
Enabled bool `yaml:"enabled"`
|
||||
FilenameExtension string `yaml:"filenameExtension"`
|
||||
|
|
|
|||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
|
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
|
||||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
|
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
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
|
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 {
|
||||
|
|
|
|||
|
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
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
)
|
||||
|
||||
type SchedPolicySwitchLogger struct {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
)
|
||||
|
||||
type SchedTraceLogger struct {
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
package elektronLogging
|
||||
|
||||
import (
|
||||
"os"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"os"
|
||||
)
|
||||
|
||||
type SchedWindowLogger struct {
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
package elektronLogging
|
||||
|
||||
|
||||
const (
|
||||
ERROR = iota
|
||||
WARNING = iota
|
||||
|
|
@ -13,4 +12,3 @@ const (
|
|||
SCHED_WINDOW = iota
|
||||
CLSFN_TASKDIST_OVERHEAD = iota
|
||||
)
|
||||
|
||||
|
|
|
|||
|
|
@ -24,9 +24,9 @@ import (
|
|||
"syscall"
|
||||
"time"
|
||||
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
)
|
||||
|
||||
func Start(quit chan struct{}, logging *bool, pcpConfigFile string) {
|
||||
|
|
|
|||
|
|
@ -29,11 +29,11 @@ import (
|
|||
"syscall"
|
||||
"time"
|
||||
|
||||
"github.com/spdfg/elektron/pcp"
|
||||
"github.com/spdfg/elektron/rapl"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/pcp"
|
||||
"github.com/spdfg/elektron/rapl"
|
||||
)
|
||||
|
||||
func StartPCPLogAndExtremaDynamicCap(quit chan struct{}, logging *bool, hiThreshold, loThreshold float64, pcpConfigFile string) {
|
||||
|
|
|
|||
|
|
@ -30,13 +30,13 @@ import (
|
|||
"syscall"
|
||||
"time"
|
||||
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/constants"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
"github.com/spdfg/elektron/pcp"
|
||||
"github.com/spdfg/elektron/rapl"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
)
|
||||
|
||||
func round(num float64) int {
|
||||
|
|
|
|||
|
|
@ -28,13 +28,13 @@ import (
|
|||
"github.com/golang/protobuf/proto"
|
||||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
sched "github.com/mesos/mesos-go/api/v0/scheduler"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/def"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
"github.com/spdfg/elektron/pcp"
|
||||
"github.com/spdfg/elektron/powerCap"
|
||||
"github.com/spdfg/elektron/schedulers"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
)
|
||||
|
||||
var master = flag.String("master", "", "Location of leading Mesos master -- <mesos-master>:<port>")
|
||||
|
|
|
|||
|
|
@ -28,12 +28,12 @@ import (
|
|||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
"github.com/mesos/mesos-go/api/v0/mesosutil"
|
||||
sched "github.com/mesos/mesos-go/api/v0/scheduler"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/def"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/utilities/schedUtils"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/utilities/schedUtils"
|
||||
)
|
||||
|
||||
type BaseScheduler struct {
|
||||
|
|
|
|||
|
|
@ -23,13 +23,13 @@ import (
|
|||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
sched "github.com/mesos/mesos-go/api/v0/scheduler"
|
||||
"github.com/pkg/errors"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/constants"
|
||||
"github.com/spdfg/elektron/def"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/utilities/mesosUtils"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/utilities/mesosUtils"
|
||||
)
|
||||
|
||||
func coLocated(tasks map[string]bool, s BaseScheduler) {
|
||||
|
|
|
|||
|
|
@ -24,10 +24,10 @@ import (
|
|||
|
||||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
sched "github.com/mesos/mesos-go/api/v0/scheduler"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/def"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
)
|
||||
|
||||
type SchedPolicyContext interface {
|
||||
|
|
|
|||
|
|
@ -19,13 +19,13 @@
|
|||
package offerUtils
|
||||
|
||||
import (
|
||||
"strings"
|
||||
"fmt"
|
||||
mesos "github.com/mesos/mesos-go/api/v0/mesosproto"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/constants"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"strings"
|
||||
)
|
||||
|
||||
func OfferAgg(offer *mesos.Offer) (float64, float64, float64) {
|
||||
|
|
|
|||
|
|
@ -20,11 +20,11 @@ package schedUtils
|
|||
|
||||
import (
|
||||
"fmt"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/def"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
"github.com/spdfg/elektron/elektronLogging"
|
||||
elekLogT "github.com/spdfg/elektron/elektronLogging/types"
|
||||
log "github.com/sirupsen/logrus"
|
||||
"github.com/spdfg/elektron/utilities"
|
||||
)
|
||||
|
||||
// Criteria for resizing the scheduling window.
|
||||
|
|
|
|||
I would alias this to elekLog as you seem to be using that prefix when aliasing imports of sub-packages.