logging: Support finer grained logging #1

Open Jookia opened this issue on 24 Aug 2021 - 1 comment

@Jookia Jookia commented on 24 Aug 2021

Logging currently specifies a priority and subsystem.

The only way to specify which logging to see is by setting the NEWLANG_LOG_LEVEL environmental variable. You should also be able to specify the subsystem, possibly with per-subsystem priorities.

Something like this:

NEWLANG_LOG_LEVEL=ALL:NORMAL,LEXER:DEBUG

Using less punctuation would be helpful.

@Jookia Jookia added the debug label on 24 Aug 2021
@Jookia Jookia changed title from Refactoring logging to logging: Support finer grained logging on 24 Aug 2021
@Jookia Jookia added the duplicate label on 24 Aug 2021
@Jookia Jookia added the logging label on 24 Aug 2021
@Jookia Jookia removed the duplicate label on 24 Aug 2021

I haven't thought about this task much for a year but now that I'm slowly running out of parser tests to write I'm looking in to old issues.

The old code used logging of every intermediate program state for debugging while new code uses tests to handle that, which doesn't require logging. When logging is required for debugging or exploration you can always add in your own print statements since there's no long compile loop.

In my experience of troubleshooting software and logs there's basically three classes of logs we need:

The first is status logs. These print a version at start and say that the program has done something successfully or failed. These are useful to figure out immediate issues with your setup.

The second is event logs. These are events in the program and state changes that make the run of your program unique, and potentially hold the secrets as to why you hit a bug but others don't. These events happen not in our program's tested code but when dealing with stuff provided to us from the user or operating system.

The third is task logs. These are the tasks and values we run out code with based on the events, and the return values. So we can see how in response to an event we run some code. This is used for figuring out why code is behaving strange.

Some of these are probably mixed, but they're all important and they happen at the boundary between our code and input or output. So focusing on logging all of our input and output seems like the direction I want to go.

Labels

Priority
default
Milestone
No milestone
Assignee
No one assigned
1 participant
@Jookia