Adding default levels settings for newly created log streams

[adam-saudagar]

Description

this PR does 2 things

1. allows create log streams using this syntax

var logger = LogStream.new(self)

so that we dont have to manually name it, and this line can be copied into other scripts and used easily

2. have an externally defined log levels, so that, it can be changed on the fly as required, without actually modifying the script where the logger is

# settings.gd

const DEFAULT_LEVELS = {
	"my_script": LogStream.LogLevel.DEBUG
}

# my_script.gd

var logger = LogStream.new(self)

var _ready():
	logger.debug("this will log")

If relevant, describe linked issues: Closes #(issue) none

Please also disclose whether there are any API changes that may effect users of the plugin.

#Checklist (replace space with X in the brackets to complete)

• [x] I have made corresponding changes to the documentation if applicable.
• [x] My code has passed the following test:
  • Reload the editor(Project->Reload current project), since godot plugins are fiddly and some errors only shows up after the plugin context has been reloaded.
  • run the res://tests/logtest.tscn scene.
  • This should produce several error messages, among one that halts the test execution and brings up the editor debugger.
  • press once.
  • Now this message should show in the engine log.
• [x] I have correctly bumped the version in the config.cfg according to the following:
  • Has form x.y.z
  • x is bumped if API breaking changes is made, these are merged restrictively.
  • y is bumped if API is added upon or modified in a way that is backwards compatible.
  • z is bumped if bugs are fixed or only internal things are changed or rearranged that doesn't change the API at all.
  • Documentation changes or comments needs no version change.
  • Read more here if unclear.

[albinaask]

Thank you for making a PR to Log. Individual log objects per object is an interesting problem, and one which I've spent much time pondering about. The main benefit is of course that you may know exactly from where the message is coming... Or you perhaps have another use case?

The issue with the approach you suggest is first and foremost that it would generate one logger per object. I.e, if you generate two enemies, they would not share the same logger. If a developer for example want to build onto the system through dumping each logger to one file each or transport it across the network, this will be a great deal more difficult. It will also create many extra objects with identical properties, which is usually not desirable.

The way I've been seeing this being solved is usually through making the instance of the logger static and renaming it, this will unable any passing of 'self' though. It's unfortunate, but I'd rather save the extra objects. I also usually only keep one Logger per section of the code, aka one for all the settings handling, one for all GUI etc. But again, this depends on one's use case. What's your use case? How do YOU use Log? What are the needs you try to fill?

It's a very interesting idea you lift of external control of log levels. I think the best solution would be to create a project setting for each logStream. What would you think of this solution?

[adam-saudagar]

Or you perhaps have another use case

my case is simple, I dont want to change the script I am logging in, but I want to change its log levels (from an ignored file) so that each dev can have their own loggers enabled depending on what modules they are working on)...

by what implementation u have currently, to do what I want to do, I would have to get the reference of logger into an external file somehow, and then call logger.current_log_level = LogStream.LogLevel.DEBUG

if you generate two enemies, they would not share the same logger

changed the code to maintain cache of created loggers and if the same one is requested, it would just return the already created one.

The way I've been seeing this being solved is usually through making the instance of the logger static and renaming it

Also, cool thing is, this way of having unique logger for each class, is completely optional... so if you prefer that u use few loggers, you can choose to do so even with the changes I made, I am just used to have different logger for each file, from the other code bases I work on. Gives me fine control over which stuff to log.

[albinaask]

I really like your ideas, and really think they should be included in Log, however your good ideas have made me come to the realization that I have to pull the trigger on a long awaited update. I'm currently in the process of offloading the main process of logging onto a separate thread, since a single call currently takes 2ms of a frametime of ~16ms. I'll merge this, or an alteration thereof after this occurs since any more code in the loop will just make it even more sluggish. So if you wonder why nothing seem to happen this is why!

[albinaask]

As of Log 2.0 Alpha 1 you may edit minimum log levels per stream from the project settings, and since these are passed as part of the project.godot file, you may have your own ones in a team through just not including the project.godot file in git or whatever or just omit the lines omitting that setting in particular if there is a lot going on in that file that needs to be shared. Bugs and suggestions are of course warmly welcome!