You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
why? it is useful, when debugging, to include larger lua objects. the logger, internally, does nothing if the log level is higher than debug, which is great.
to render tables, etc, though, someone needs to use a pretty-printer on them. if I do that to the argument then I'm rendering a table to a string which is then completely ignored, and that is kind of not cool. especially if I'm in the context of a high frequency callback.
if the logger did that internally, though, it could delay that work until later: when it decides the event should be logged, it then spends the time turning the object into a string. that way I don't need to think about the "cost" of dumping an object so much.
I can implement this manually, by testing the logger level by hand—but that required poking my nose into the implementation to figure out how to ask "is the logger going to do something with a debug message?"
FWIW, you can approximate your second example suggestion with hs.inspect(tbl, { newline = " ", indent = "" }).
I agree that this would make logger more useful with tables. I would like to point out that there are a few cases where tables are used like userdata and already have a __tostring method, so there should probably be some logic like:
...iftype(item) =="table" thenif (getmetatable(item) or {}).__tostringthen-- use tostring(item)else-- use hs.inspect(item, { newline = " ", indent = "" })endend...
I think if this change is made, it would annoy me, as a lot of the time I use hs.logger to double check the type of something, so I actually just want to see something like table: 0x6000017a88c0 rather than printing out the contents of the table.
Maybe there could be a new method added to hs.logger so it doesn't break existing functionality? For example:
why? it is useful, when debugging, to include larger lua objects. the logger, internally, does nothing if the log level is higher than debug, which is great.
to render tables, etc, though, someone needs to use a pretty-printer on them. if I do that to the argument then I'm rendering a table to a string which is then completely ignored, and that is kind of not cool. especially if I'm in the context of a high frequency callback.
if the logger did that internally, though, it could delay that work until later: when it decides the event should be logged, it then spends the time turning the object into a string. that way I don't need to think about the "cost" of dumping an object so much.
I can implement this manually, by testing the logger level by hand—but that required poking my nose into the implementation to figure out how to ask "is the logger going to do something with a debug message?"
current behaviour:
desired behaviour:
or better, but not really in reach with the upstream library:
The text was updated successfully, but these errors were encountered: