Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Wanda makes a lot of noises in the log #1479

Closed
lasers opened this issue Sep 2, 2018 · 3 comments
Closed

Wanda makes a lot of noises in the log #1479

lasers opened this issue Sep 2, 2018 · 3 comments

Comments

@lasers
Copy link
Contributor

lasers commented Sep 2, 2018 •
edited
Loading

Hi friends. I adore wanda_the_fish too much. I am a horrible father for abandoning wanda_the_fish everytime I collaborate on py3status. I'd like an option to adjust log verbosity or to simply turn off the logs. Exceptions should always be kept in the logs too.

I also think it'd be great if we could default wanda_the_fish with no logs.

I'm thinking about a per-module/global option too... that can tune out the noises in other modules without turning them off... by redirecting attention toward this module only... rather than to keep working and/or grepping through all the noises.

Here's a list of some modules that already make lot of noises.

  • backlight.py: cache_timeout = 10
  • dpms.py: cache_timeout = 15
  • file_status.py: cache_timeout = 10
  • gpmdp.py: cache_timeout = 5
  • keyboard_layout.py: cache_timeout = 10
  • keyboard_locks.py: cache_timeout = 1
  • lm_sensors.py: cache_timeout = 10
  • loadavg.py: cache_timeout = 5
  • pomodoro.py: cache_timeout = 0
  • spotify.py: cache_timeout = 5
  • timewarrior.py: self.cache_timeout = 0
  • wanda_the_fish.py: cache_timeout = 0
  • window_title.py: cache_timeout = 0.5
  • xsel.py: cache_timeout = 0.5

It's not worth to list all modules that can refresh every <= 20 seconds, but you get the idea.

Help me be a great dad to wanda_the_fish. 🐠 👨
@lasers lasers added the feature request 🙏 I am requesting a feature label Sep 2, 2018
@tobes
Copy link
Contributor

tobes commented Sep 2, 2018

maybe just turn of debug mode https://py3status.readthedocs.io/en/latest/intro.html#options

but yes per module debugging would be nice at some point. It is generally too noisy so I never really have it turned on. but if it was more clean then I'd probably use it. Even in core it would be good to have limits on what is logged in debug mode as in which chunks of the code, events, modules, formatter ... but for modules it'd be simple enough to implement.

Also talking of noise try to keep you comments succinct too :).

@tobes tobes removed the feature request 🙏 I am requesting a feature label Sep 2, 2018
@tobes
Copy link
Contributor

tobes commented Sep 2, 2018

A feature request is a specific thing this is a ramble

@lasers
Copy link
Contributor Author

lasers commented Sep 2, 2018

Okay, I turned off debug. I'll see if I can get used to this. I often leave this on to identify or study module issues and/or behaviors better between intervals.

Feature is that I am looking for a way to filter out other modules, but still keep core, startup, exceptions, etc on... I often need this only when I'm working on a new module... or a new module from scratch. Maybe it's an non-issue with debug off and I can always try to grep things with debug off too.

I go ahead and close this feature request and/or ramble.

@lasers lasers closed this as completed Sep 2, 2018
rlerm added a commit to rlerm/py3status that referenced this issue Sep 4, 2021
@rlerm
Use the logging module directly instead of home-grown code.
d3436d4 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Sep 4, 2021
@rlerm
Use the logging module directly instead of home-grown code.
60cde69 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
@rlerm rlerm mentioned this issue Sep 4, 2021
Open
rlerm added a commit to rlerm/py3status that referenced this issue Sep 19, 2021
@rlerm
Use the logging module directly instead of home-grown code.
88361de 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Sep 20, 2021
@rlerm
Use the logging module directly instead of home-grown code.
ff34d7b 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Jan 31, 2022
@rlerm
Use the logging module directly instead of home-grown code.
4b2ee49 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Jan 31, 2022
@rlerm
Use the logging module directly instead of home-grown code.
ae4ccbc 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Jan 31, 2022
@rlerm
Use the logging module directly instead of home-grown code.
5ebd7bf 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
rlerm added a commit to rlerm/py3status that referenced this issue Jan 31, 2022
@rlerm
Use the logging module directly instead of home-grown code.
37b19a5 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
d209da3 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
e369540 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
ea301b0 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
0e636e0 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
5efa975 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
8f5fceb 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
61c4ae3 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Use the logging module directly instead of home-grown code.
35f16c4 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 21, 2024
@rlerm @lasers
Set up standard logging module
afed0e8 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Jan 24, 2024
@rlerm @lasers
Set up standard logging module
e68588a 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
lasers pushed a commit to lasers/py3status that referenced this issue Feb 5, 2024
@rlerm @lasers
Set up standard logging module
318ccce 
This has the advantage of overall less custom code; as well as support
for per-module configuration. This would enable a potential solution for
ultrabug#1479, since in the future
it can allow per-module configuration of log levels.

I expect this to mainly help module creators, allowing them to enable
logging for only their module, while disabling all other messages. It
also is easier to use, since the `logging` module's interface is
generally simpler than `self.py3`.

Here, I've made the decision to keep the message format as close as
possible to the existing log messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tobes @lasers