Outputting log levels

[Brendan]

I think that there are edge cases not properly being described in RF24StreamLogHandler::appendLogLevel() The way I understand it is

• 0 is reserved for disabling loggers
• 1-7 are not described by any main levels
• 8-0xF describe all ERROR levels
• 0x10-0x17 describe all WARN levels
• 0x18-0x1F are not described by any main levels
• 0x20-0x27 describe all INFO levels
• 0x28-0x2F are not described by any main levels
• 0x30-0x37 describe all DEBUG levels
• 0x38-0xFE are not described by any main levels
• 0xFF describes an ALL level (though I'm not sure we need this enumeration because its not accounted for in the current switch ... case block nor in the rf24LogLevels array of c-string descriptions)

Notice the gaps between the levels (another reason I prefer sublevels follow a decimal system). So, the cases in the current source code account for all usual "main" levels but only if logMainLevel == 0x08, 0x10, 0x20, 0x30; any of the numerous non-described sublevels would look like "Lvl xx" and have no main level domain.

@wmarkow I remember you expressed concern about using a decimal system since level % 10 would consume more resources to compute. I'm just trying to point out how easy/confusing it would be for an uninformed user to exploit the gaps in main log levels.

[Witold Markowski]

I think there is no gaps between log levels:

• 0x00 is reserved for disabling loggers
• 0x01-0x07 are not described by any main levels
• 0x08-0x0F describe all ERROR levels
• 0x10-0x17 describe all WARN levels
• 0x18-0x1F describe all INFO levels
• 0x20-0x27 describe all DEBUG levels
• 0x28-0xFE are not described by any main levels
• 0xFF describes an ALL level

See how log levels are defined in RF24LogLevel.h

[Brendan]

ok my mistake, but we should use an octal notation if we're going to follow an octal counting system. Again this is really weird coming from python's logging lib.

[Brendan]

    switch (logMainLevel) {
        case RF24LogLevel::ERROR:
            stream->print(rf24LogLevels[0]);
            break;
        case RF24LogLevel::WARN:
            stream->print(rf24LogLevels[1]);
            break;
        case RF24LogLevel::INFO:
            stream->print(rf24LogLevels[2]);
            break;
        case RF24LogLevel::DEBUG:
            stream->print(rf24LogLevels[3]);
            break;
        default:
            // unknown
            if (logLevel < 10) {
                stream->print("Lvl   ");
            }
            else if (logLevel < 100) {
                stream->print("Lvl  ");
            }
            else {
                stream->print("Lvl ");
            }
            stream->print(logLevel);
            stream->print(" ");
            return;
        }
    }

could be reduced to

if (logLevel & 0x38 && logLevel & 0x38 <= 040) {
    stream->print(rf24LogLevels[(logLevel & 0x38 >> 3) - 1]);
}
else {
    if (logLevel < 10) {
        stream->print("Lvl   ");
    }
    else if (logLevel < 100)  {
        stream->print("Lvl  ");
    }
    else  {
        stream->print("Lvl ");
    }
    stream->print(logLevel);
    stream->print(";");
 }

Also keep in mind that trying to keep the output "pretty" costs us extra memory

[Brendan]

I'm also used to seeing : delimit the various message prefixes instead of (1 space). Imagine if someone wants to parse the logged messages programatically, then a space char would be more difficult to differentiate from the spaces used in non-described levels and any spaces in the message itself ("<timestamp> Lvl xx This is a message")

we could use a ; instead if ctime (on Linux) outputs a timestamp with : as a delimiter (HH:MM:SS)

[Witold Markowski]

@2bndy, you are right; the switch can be simplified and reduced a bit. Also we can change the space into ; I can provide a PR with your suggestions for this issue, but it would be good to merge #7 before.

[Brendan]

I went ahead and changed the log levels to use octal notion before merging #7, so maybe do a rebase with whatever branch you're working from.