New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log levels and modules - v0.2 milestone #1388
Conversation
LOG_PREFIX didn't have to be an argument if we make sure that symbol is always in scope |
I had made a test from AppVeyor (release build), it does not seem to output any of the specific log info to console. Almost as if nothing has change. EDIT: See my second comment below. I discover a bug for "Emulator" event list. If I enable all, close emulator, re-open, open logging dialog window. Then SMC checkbox is unchecked. Also, accept / cancel button is a requirement in case anyone decide to not save the new change. As for sending log configured update over to runtime emulation does not make any sense. It should be static to keep the log more complete. Plus there is an hotkey to toggle the output log. |
Actually, the reason LOG_FUNC_BEGIN and debug messages are on debug build is because of no log filter support. Plus we need release build to able output these as well since log filter, this pull request, is now supported. Then we can finally have our testers to send it to one of developer/contributor for specific filter to review through without intensive going through all outputs greater than 1 GB or more file size in matter of seconds. |
@PatrickvL I dropped the LOG_PREFIX parameter from the debug macros, but I can’t do the same with EmuLog and DbgPrintf because there are instances where they do not use the default LOG_PREFIX defined in the current translation unit (e.g.: EmuLog in WM_COPYDATA, in CxbxPopupMessage, in EmuXB2PC_D3DMultiSampleFormat, DbgPrintf in CxbxKrnl.cpp). |
resource/Cxbx.rc
Outdated
@@ -43,6 +43,22 @@ BEGIN | |||
BOTTOMMARGIN, 207 | |||
END | |||
|
|||
IDD_CONTROLLER_CFG, DIALOG |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reason for add these with empty fields? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn’t do it, it must have been VS when I used the resource editor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, let's leave it as is.
Other than above fixes, there are some output (such as shader, old/new file paths, etc) shouldn't be in unfiltered log output. I think former developer(s) did this on purpose. We will fix any unfiltered logs later on. |
@RadWolfie Here is a reason to have dynamic logs: what if you have a game with a bug of unknown origin and the relevant log doesn’t show up with the current settings? If the program doesn’t support changing logging settings at runtime, then you have to close it, change settings and relaunch it until the interesting log shows up, which can become annoying if you have to do this repeatedly or you have to play for a long time until you reach the actual section of the game with the bug. This is a typical use case of dynamic logging. With it, you can keep logging at a minimum when not needed and only increase it when you reach the affected area. The hotkey won’t help since it’s not specific and disables everything. |
There is 2 things (bug/feature) concerning logging stuff:
|
If I understand above comment...
|
|
This looks pretty solid now. What issues remain could be done later I guess? |
There was a conflict before which should have been solved now. The other two problems mentioned by @gandalfthewhite19890404 can be done later as they have a separate issue. |
* Reduce duplicate methods perform same task into one simple function. * Use EmuShared to obtain updated log settings instead of WM_COPYDATA message. * FIXED: Set log config for second GUI process * FIXED: Proper update logging config to EmuShared instead of repeatly send when it is indeed in use. * Without this fix, it will affect other GUI process emulating a title.
I agree with @ergo720 since other two problems are not directly relative to this pull request, log filter feature, and are part of feature requests. That's all the bugs I found with some clean up of duplicate methods. I can confirm new commit I made does work on my end even with second GUI process running. |
This could be very useful for debugging scenarios without the log being polluted by other modules, thanks! That said, I'm happy to merge |
Awsome job, thanks! |
We know about this, not all logs are being filtered. It is not affecting this pull request by the way. Even shader compiler are outputting too with log filter disabled. |
Having multiple build types for each branch is proving to be confusing for some users. Ever since we implemented #1388, there has been no end-user benefit for using Debug builds, as they can get the same logging result by toggling the log level to Debug
Ready for merging!
This implements log levels and modules. If the level of the event is less than the current selected level, it won’t be printed. If the module if off, all its event won’t be printed regardless of the level. Also note the messages printed with printf will always be printed independently of level and modules. This is useful if you want to always print a message (e.g.: xbe signature check to avoid disabling its printing in the log).
Other messages will only be printed on debug builds (e.g. DbgPrintf, LOG_FUNC_BEGIN) because on release builds their macro decays to a null function or it’s empty, but they will still respect log levels and modules.Finally, a new logging window has been added to the gui to let users modify the log parameters, also at runtime.