Open lmbr-pip opened 1 year ago
Should we also remove the concept of window
from AZ_TracePrintf/AZ_Trace?
Should we also remove the concept of
window
from AZ_TracePrintf/AZ_Trace?
Well to be consistent with AZ_Warning and AZ_Error would would still need the "window" parameter. That being said I think the Window parameter is unnecessary to the trace system as the caller could specify any prefix information as part of the trace message itself, it inhibits output of trace messages without an intermediate buffer which results in lower trace performance.
Examining the Feature design description section, I do have one question about the deprecation phase of AZ_TracePrintf
.
Will it output at the new "info" log level while deprecated or it will use the "trace" log level.
Having AZ_TracePrintf log at "trace" log level encourages authors to update their uses to use the appropriate AZ_Trace
or AZ_Info
level as they would need to make a manual local change to lower the log level to trace
.
The reason of the proposal looks good to me.
I think time period wise, if we have the AZ_TracePrintf
remain at the "trace" log level, while making the default "info", then I say we can wait for two releases after the implementation of this feature to remove usages of AZ_TracePrintf
while we can immediately encourage users to use the AZ_Trace/AZ_Info
macro as soon as the feature is in.
One alternative of removing the AZ_TracePrintf
macro define at the end of the deprecation phase, is have it be no-op, so that existing code will still compile, but will no longer receive trace or info messages until they update their macros.
On issue I have with the window parameter is that it prevents a useful feature of Visual Studio that if you output a log with the format __FILE__(__LINE__): <description>
you can double click on that log entry and VS will take you to that file + line. I know it seems simple, but the amount of time it saves is considerable. That said, I think this only applies to AZ_Assert
, however, AZ_Debug
could leverage it as well as it's a developer tool that could help navigate quickly through logged messages.
@lumberyard-employee-dm
Plan is to:
AZ_TracePrintf
as deprecated and begin to encourage shift to new macrosAZ_TracePrintf
level down to trace.AZ_TracePrintf
-> AZ_Trace
usage.AZ_TracePrintf
AZ_TracePrint
and AZ_TracePrintfOnce
@lsemp3d
@lumberyard-employee-dm
Plan is to:
* [ ] Provide new macros. See [Add new AZ_Trace and AZ_Info macros o3de#13851](https://github.com/o3de/o3de/pull/13851) * [ ] Mark `AZ_TracePrintf` as deprecated and begin to encourage shift to new macros * [ ] Wait "some time" and then drop `AZ_TracePrintf` level down to trace. * [ ] Convert existing `AZ_TracePrintf` -> `AZ_Trace` usage. * [ ] Null OP `AZ_TracePrintf` * [ ] Remove `AZ_TracePrint` and `AZ_TracePrintfOnce`
@lsemp3d
* For now, removing Window is non-trivial and beyond time commitment I can make for this change. Would love to see after this change, a proposal for a unified, up-to-date, logging implementation for O3DE.
The plan looks good to me. I think there is one minor piece of information missing and that is in bullet 2, the AZ_TracePrintf
will be initially set to be at the info
log level.
It would only be necessary to remove the (System) one that is emitted by errors and asserts by default, not the entire concept of Window in order to enable the functionality in Visual Studio. This much is fairly straightforward.
This RFC has been signed off by @o3de/sig-core and the change is free to go into development.
Action Plan
AZ_TracePrintf
to trace levelAZ_TracePrintf
to AZ_Trace
(1 month later)AZ_TracePrintf
from code under breaking change condition and close out deprecation noticeMigrate some PerformanceCollector AZ_TracePrintf to AZ_Trace: https://github.com/o3de/o3de/pull/15433
Summary:
Add new
AZ_Info
andAZ_Trace
log macros to enable separation of log levels for trace level logging; these macros will replace the use ofAZ_TracePrintf
, which will be deprecated.What is the relevance of this feature?
O3DE lacks separation of info level log statements from debug trace.
O3DE has the notion of the following log levels, provided by ILogger - the AZ interface for logging, Debug/Trace debug log macros and ILog legacy log reporting from CrySystem code, for reporting assert, errors, warnings, and informational messages:
For reference, looked at other common log platforms or approaches:
A lot of existing O3DE code uses the
AZ_TracePrintf
which mixes informative messages, with often fine-grained informational events that are most useful to debug an application. This RFC proposes splitting that macro up to have a clean separation for Debug/Trace users.Feature design description:
Trace
level toLogLevel
AZ_TracePrintf
as deprecated in code.AZ_Trace
macro to log atTrace
level.AZ_Info
macro that logs atInfo
level.Info
in both systems.AZ_TracePrintf
.AZ_TracePrintf
withAZ_Trace
.Technical design description:
As RFC is proposing two new AZ_Info macros, all the technical description has been added that's relevant.
Note: There is a proposal to add UX for log level control in the Editor, See https://github.com/o3de/sig-content/blob/main/rfcs/rfc-69-logging-event-viewer.md
What are the advantages of the feature?
What are the disadvantages of the feature?
GetErrorReport()
,QMessageBox::critical
,CLogFile
How will this be implemented or integrated into the O3DE environment?
AZ_TracePrintf
withAZ_Trace
usage.Are there any alternatives to this feature?
However, this RFC could be a stepping stone on those paths as it provides an immediate solution. It does not block a more extensive logger redesign.
How will users learn this feature?
Are there any open questions?