-
Notifications
You must be signed in to change notification settings - Fork 86
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
[EventGhost] - Enhancement - Log.py, Upgrades the debug logging #249
base: master
Are you sure you want to change the base?
Conversation
Changes the debug logging to find the name of the calling module and if it is a plugin it will create a new file specifically for that plugin. Provides alittle more organization to the debug logging.
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 personaly don't like to have the log splitted, but that's just me. Don't know what others say. I hope we get some more comments.
eg/Classes/Log.py
Outdated
'Windows Version: %s' % ' '.join( | ||
list(platform.win32_ver()) | ||
), | ||
'Computer Name: %s' % platform.node(), |
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.
Do we really need the computer name for debugging?
), | ||
'Python Compiler: %s' % platform.python_compiler(), | ||
'Python Build Date: %s' % ( | ||
platform.python_build()[1], |
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'm missing the info that it's stackless python, so i would just use sys.version
. It returns '2.7.12 Stackless 3.1b3 060516 (default, Oct 31 2016, 18:42:08) [MSC v.1500 32 bit (Intel)]'
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.
ok can do
I'll do it right now
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.
do you like the way it works tho? I likle it alot better. it is a pain in the backside to sift through a debug log file when you are looking for something that is specific to a plugin. This is a nice way to handle it.
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.
maybe if i would use EG more then i would find it more usefull :D but i will merge it anyway ;)
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.
all done.
Adds the Stackless version to the log header
if split logging is to be used the config.py file needs to be edited and the line splitDebuggingLog = True needs to be added to it in order to turn on this feature. added for printing the header information to the original Log output. removed the computer name from the header.
corrected the python version. added the ability to turn on or off the slpit logging via adding a line to the config.py file
made it so that each time the debugging log is turned on or off it will set a flag for printing the header to the original Log.txt |
Oh and this will only split off the plugins and nothing else. I am not usually one for split logs either. But when i specifically am looking for output form a plugin i am working on it's an annoyance to have to go reading through a large log and this way I am also able to only delete that plugins log. |
Thanks for adding the split option 😃 |
I do not think anything else needs to be added. just want to make sure it works 100% because it does have some voodoo code to it. and that is not my favorite kind of code. but it's the only way to do it without adding a method to the plugin base. and then having the plugin devs update their plugins to support it. so i though this would be a better way |
Now EG only works if i have |
Had to move eg.Config being initiliazed to before eg.Log due to the log needing an attribute from eg.config. Also did some code optimization. and removed the use of os to get the appdata folder.
i just wanted to let you know this one should be fixed. i forgot to mention it. i did a commit a while back |
well, sorry to say no. I've deleted Appdata\EventGhost and then run EG with -debug option. The GUI doesn't show up, the process seems to hang and a log file with only |
after it runs normally if you then close EG and restart it with the -debug parameter does it work then? |
No, makes no different if i run it successfully before using -debug. |
Changes the debug logging to find the name of the calling module and if it is a plugin it will create a new file specifically for that plugin. Provides alittle more organization to the debug logging. It also houses all of the log files into a folder called logs in %appdata%\EventGhost.
It also fixes the issue of not having the debug header information added if the user has logging turned on from inside of the GUI. and I added the Windows version, Windows major, minor, build version, the start time of EG is all added to this header also. The header is added to each new file that is made or appended to one that is already existing. It closes the file after each write to it so it can be deleted without the need to shutdown EG.
If there happen to be any error during the load of EG this information will be written to the standard Log.txt file. and anything that is not a plugin that is writing log information is written to Core.txt in the logs folder.