Opened 4 years ago

Last modified 4 years ago

#9837 new task

Introduce a logging API to GHC

Reported by: rodlogic Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I don't have a lot of mileage with the code base, but I do see that there is no standard logging API that the various components can use (or there is and it just needs to be used??).

At least, I would expect to see a standard API to generate log entries with the following minimal parts:

  • timestamp
  • Log level - for example, ERROR, WARN, INFO, DEBUG, TRACE (-v[1-3] could map to INFO, DEBUG and TRACE. Log levels are inclusive so INFO also means WARN and ERROR.
  • Component name - so we know what is the source of the log message. At least I would expect to see (Desugarer, Typechecker, Parser, etc)
  • the message

It would also mean a single back-end to collect the log messages and dump them to a file, stdout/stderr, etc. There are many other features beyond this point (customize log messages, colors, filtering, etc), but in terms of the API that is used throughout the code base, it should be simple.

Was this already discussed in the past? Is there already such an API in the codebase? Is there an existing library that we could use to achieve the same? Any other ideas?

This ticket is mostly to spawn a discussion about it.

Change History (3)

comment:1 Changed 4 years ago by carter

I think the ghc events log already provides the machinery for this sort of thing. I dont think that those notions of log levels necessarily make sense in the RTS though. (though i could be wrong)

comment:2 Changed 4 years ago by rodlogic

Yes, I opened the ticket thinking about the compiler not the runtime. Right now if you turn the verbosity on you will see a blob of output that is hard to parse and could benefit from a tidy up.

Maybe the current v[1-3] is already good enough, I think the main point is to centralize logging. Again, if there is a pattern to this that I am missing here, please let me know.

comment:3 Changed 4 years ago by goldfire

Can you describe an intended consumer of such a log?

To my knowledge, there is no centralized logging structure, per se, although there are plenty of -d flags that dump log-like output. There is some central management of these flags, but I don't think there's a ton of consistency about this. However, before trying to shore this up, it would be helpful to know what a consumer would look like.

Note: See TracTickets for help on using tickets.