Giter Club home page Giter Club logo

Comments (7)

Reidmcc avatar Reidmcc commented on August 12, 2024

I could have a go at this one. Before I get started, what level of generalization are you thinking of?

I'm envisioning something like functions that format and return messages in a particular category in a consistent logging framework format. For example all log messages that are errors would be the same color and have the same metadata elements. Is that the right track?

from kelp.

nikhilsaraf avatar nikhilsaraf commented on August 12, 2024

@Reidmcc yes that's the right track.

You can start by creating a basic interface in the (new) support/logging package like so:

type Logger interface {
    // basic messages, appends a newline (\n) after each entry
    Info(msg string)

    // basic messages, can be custom formatted, similar to fmt.Printf. User needs to add a \n if they want a newline after the log entry
    Infof(msg string, args ...interface{})

    // error messages, indicates to the logger that these messages can be handled differently (different color, special format, email alerts, etc.). The type of logger will determine what to do with these messages. The logger should NOT panic on these messages. Appends a newline (\n) after each entry.
    Error(msg string)

    // error messages, indicates to the logger that these messages can be handled differently (different color, special format, email alerts, etc.). The type of logger will determine what to do with these messages. The logger should NOT panic on these messages. User needs to add a \n if they want a newline after the log entry.
    Errorf(msg string, args ...interface{})
}

It would be best to start with the following:

  • interface definition
  • 1 implementation with the current log type logger
  • converting over one file first, maybe trade.go.

We can handle structured logging later since that will be a specific implementation of this interface.


We should be able to nest loggers when creating them, example:

Logger logger := logging.BufferedLogger(
    logging.MakeMultiLogger(
        logging.MakeDateLogger(
            logging.MakeColoredLogger(
                logging.MakeFileLogger("myLogFile.log"),
                logging.ColorBlack,        // color for Info logs
                logging.ColorRed,          // color for Error logs
            )
        ),
        logging.MakeNetworkLogger("https://my-logging-url.com"),
    ),
    10,    // number of entries to buffer before sending to its inner logger
)

In the above example, the outermost logger will buffer up to 10 log entries before sending to its inner logger. The MultiLogger will send each entry to it's list of inner loggers. The DateLogger will prefix the date to each message before passing it on to its inner logger. The coloredLogger will modify the message so it is displayed with color. The file logger will log to a file called myLogFile.log. The second logger (passed to the multiLogger) will send the log lines to the network endpoint.

With the above interface and such a composable logger we can come up with a variety of different log setups with just a few basic components. The first component can be very basic which uses our existing log library.

The most important part in this task is to convert the existing log lines from Printf and Println statements to use the above interface.


The variable name for the logger object in each file should be standardized to logger so we can easily search for places in the code where we do not use this logger and use log instead.

Let me know if you have any questions.

from kelp.

Reidmcc avatar Reidmcc commented on August 12, 2024

Ok, sounds good. So right now there are just these steps:

  1. Set up the logger interface
  2. Switch all the log messages to use that interface
  3. Make sure it can still output to file

And specifically not to create any complex loggers like the web logger example.

from kelp.

nikhilsaraf avatar nikhilsaraf commented on August 12, 2024

yes, you got all that correct.

on the output to file, that will still use the current logic that you had added previously (i.e. we will not have a separate fileLogger and regular logger for the first implementation, just a LogLogger implementation).

from kelp.

jmg421 avatar jmg421 commented on August 12, 2024

I know nothing about how to do this sort of thing but am happy to help. I have kelp v1.4.0 installed on my Mac.

from kelp.

nikhilsaraf avatar nikhilsaraf commented on August 12, 2024

@jmg421 You should compile the latest version of Kelp from source, see the README for how to do this along with setting up the necessary tools. I'd recommend creating a new branch in your own fork for this project.

You can then start refactoring the log lines one file at a time from log.Printf to l.Infof and l.Errorf, and fatal errors to logger.Fatal. See a sample commit that does this here for the `cmd/trade.go file. You can then submit PRs against those changes to be included in the master branch. Please keep your Pull Requests to be for 1 PR per file. This will allow the code reviews to go quicker.

Let me know if you have any questions along the way!

from kelp.

jmg421 avatar jmg421 commented on August 12, 2024

Will do; need to get my environment set up first which will take a little while... i'm a complete n00b

from kelp.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.