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.

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

replace --controller-debug command line argument with Qt logging categories #4239

Closed
wants to merge 7 commits into from

Conversation

Be-ing
Copy link
Contributor

@Be-ing Be-ing commented Aug 22, 2021

Logging is separated into several subcategores:
controller.CONTROLLERNAME: general messages
controller.CONTROLLERNAME.input: incoming data
controller.CONTROLLERNAME.output: outgoing data

CONTROLLERNAME is the lowercase device name with non-alphanumeric
characters removed.

This allows more fine tuned control of what messages are shown
in the console. This is required for the logging output to be
useful with controllers that continually send input such as the
Native Instruments Traktor Kontrol S4 Mk3 and Gemini GMX (ping @codecat).

This will be required to use it in a QLoggingCategory which has a
deleted copy constructor.
@Be-ing Be-ing requested a review from Swiftb0y August 22, 2021 04:52
@coveralls
Copy link

coveralls commented Aug 22, 2021

Pull Request Test Coverage Report for Build 1160722086

  • 77 of 234 (32.91%) changed or added relevant lines in 11 files are covered.
  • 17 unchanged lines in 8 files lost coverage.
  • Overall coverage increased (+0.05%) to 26.018%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/control/controlobjectscript.cpp 7 14 50.0%
src/controllers/scripting/legacy/controllerscriptenginelegacy.cpp 11 18 61.11%
src/controllers/midi/midioutputhandler.cpp 0 8 0.0%
src/controllers/controller.cpp 11 21 52.38%
src/controllers/midi/portmidicontroller.cpp 19 29 65.52%
src/controllers/bulk/bulkcontroller.cpp 0 18 0.0%
src/controllers/scripting/legacy/controllerscriptinterfacelegacy.cpp 20 39 51.28%
src/controllers/midi/midicontroller.cpp 4 33 12.12%
src/controllers/hid/hidcontroller.cpp 0 49 0.0%
Files with Coverage Reduction New Missed Lines %
src/control/controlobjectscript.cpp 1 81.82%
src/controllers/bulk/bulkcontroller.cpp 1 0%
src/controllers/controller.cpp 1 48.78%
src/controllers/midi/midioutputhandler.cpp 1 0%
src/controllers/scripting/legacy/controllerscriptenginelegacy.cpp 1 50.72%
src/controllers/midi/midicontroller.cpp 2 30.28%
src/engine/cachingreader/cachingreaderworker.cpp 2 63.48%
src/controllers/scripting/legacy/controllerscriptinterfacelegacy.cpp 8 43.61%
Totals Coverage Status
Change from base Build 1154301022: 0.05%
Covered Lines: 20064
Relevant Lines: 77117

💛 - Coveralls

@Swiftb0y
Copy link
Member

I can't comment much on the code without researching the Qt APIs myself first. @uklotzde is probably the more fitting person to review this.
Conceptually, the changes seems sensible though.

@Swiftb0y Swiftb0y requested a review from uklotzde August 22, 2021 09:42
@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 22, 2021

Unfortunately there is no API to set the QLoggingCategory that console.* calls from JavaScript get sent to; they all go to the js logging category. I made a feature request for Qt to add that.

@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 22, 2021

The way the filter rules work confuses me.

QT_LOGGING_RULES="controller*input.debug=false;controller.*.debug=true"

and

QT_LOGGING_RULES="controller.*.debug=true;controller*input.debug=false"

do not work to hide the input messages from the controller, but

QT_LOGGING_RULES="controller.*.debug=true;*.input.debug=false"

does work. 🤷

@uklotzde
Copy link
Contributor

The way the filter rules work confuses me.

QT_LOGGING_RULES="controller*input.debug=false;controller.*.debug=true"

and

QT_LOGGING_RULES="controller.*.debug=true;controller*input.debug=false"

do not work to hide the input messages from the controller, but

QT_LOGGING_RULES="controller.*.debug=true;*.input.debug=false"

does work. shrug

Probably similar to GitHub actions expression syntax where there simple wildcard * is not recursive and does not match separators. Unfortunately, there doesn't seem to exist a recursive ** wildcard for Qt logging rules.

@Be-ing Be-ing force-pushed the controller_logging_categories branch 3 times, most recently from 606cb08 to 7e43d38 Compare August 23, 2021 14:16
@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 23, 2021

The pre-commit failure is complaining about a legacy mapping script. Fixing that is beyond the scope of this PR. We cannot simply apply eslint's patches without testing with real hardware because they can break scripts.

@Be-ing Be-ing force-pushed the controller_logging_categories branch 2 times, most recently from 92aca80 to ed02ced Compare August 23, 2021 15:08
@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 23, 2021

I renamed DynamicLoggingCategory to RuntimeLoggingCategory. I think DynamicLoggingCategory is a bit misleading because it could be misunderstood to mean that the category name can be changed after the class is instantiated.

@Be-ing Be-ing force-pushed the controller_logging_categories branch from ed02ced to 72af3ba Compare August 23, 2021 15:12
Copy link
Contributor

@uklotzde uklotzde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check for all trivial format strings like "%1" that should be replaced.

@Be-ing Be-ing force-pushed the controller_logging_categories branch 2 times, most recently from d63269d to 395b4f4 Compare August 23, 2021 20:19
@Holzhaus
Copy link
Member

Holzhaus commented Aug 23, 2021

Is this a breaking API change that makes all old mappings that use print/engine.log incompatible with Mixxx 2.4? I'm wondering because you changed controller mappings in this PR.

@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 23, 2021

No, there are no breaking changes for mapping scripts. I changed the print function in common-controller-scripts.js to use console.log instead of engine.log and changed the implementation of engine.log to warn that it is deprecated and to use console.log instead. There was only mapping that used engine.log directly instead of print which was the Hercules 4 Mx mapping, so I did a find-and-replace to update that.

@github-actions github-actions bot added the build label Aug 24, 2021
@Be-ing Be-ing force-pushed the controller_logging_categories branch from 7382c5e to 4b9fc5a Compare August 24, 2021 00:18
@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 29, 2021

@daschuer
Copy link
Member

It looks like #2635 was a not working attempt to fix https://bugs.launchpad.net/mixxx/+bug/1871238 we have missed to revert. It was merged on 2020-08-04 to git7232 and we have a report that git7243 is still crashing. It was finally fixed on 2020-04-12 by mixxxdj/buildserver#86.

@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 30, 2021

Thank you for digging into that history. We should remove the misleading comment.

@Be-ing
Copy link
Contributor Author

Be-ing commented Aug 30, 2021

I think manipulating the filter rules with the legacy --controller-debug option is not a good idea. Now the controller debug messages are shown with --log-level debug. There is no need for an extra command line switch to enable the controller debug messages separately, which I found confusing before. If you want to disable the controller debug messages and only see the other debug messages, you can set the Qt logging rules.

@daschuer
Copy link
Member

I don't really mind, but the current state was just fine IMHO. Enable controller debug by default will puts the burden on everyone to find out how to get rid of the fast scrolling debug output when dealing with an other unrelated problem. From other projects I know that debug categories have to be enabled one by one on demand.

What do others think?

The alternative would be to print a message how to switch controller debugging when someone uses --controlerDebug

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 4, 2021

Merge?

@daschuer daschuer closed this Sep 4, 2021
@daschuer daschuer reopened this Sep 4, 2021
@daschuer
Copy link
Member

daschuer commented Sep 4, 2021

Merge?

No, it is a regression to fail if the --controlerDebug flag is set without enable or suggest the workaround.

I would prefer to keep the old default behavior unchanged. This way we can also remove the log file hack introduced here.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 4, 2021

We do need to document new behavior, but I don't think we need to add an explanation in Mixxx for every behavior change, especially not for something that only affects developers.

It has been replaced by categorized logging.
@Be-ing Be-ing force-pushed the controller_logging_categories branch from ac77958 to daf74e6 Compare September 26, 2021 18:44
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 26, 2021

It is silly that this isn't merged already. If it isn't merged soon I'm just going to close it.

@daschuer
Copy link
Member

Be-ing force-pushed the ...

Please remember, we have the rule to not to rebase a PR under review. If a re-base is necessary please ask before.

@daschuer
Copy link
Member

For my understanding we have exchanged strong arguments towards not silently removing "controllerDebug".
I feel not comfortable to merge this without.

@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 26, 2021

I've already responded to those arguments. I'm not going to continue arguing.

@Be-ing Be-ing closed this Sep 26, 2021
@Be-ing
Copy link
Contributor Author

Be-ing commented Sep 27, 2021

It is a shame that solving real problems continually gets obstructed by bikeshedding minor hypothetical issues.

@uklotzde
Copy link
Contributor

uklotzde commented Sep 27, 2021

It is a shame that solving real problems continually gets obstructed by bikeshedding minor hypothetical issues.

I second that. With this attitude development of Mixxx will stall and get stuck.

@Swiftb0y
Copy link
Member

I'd like to revive this PR.
Mixxx is not a console application. We should be allowed to have breaking changes in commandline flags, especially in minor releases. If somebody wants to make use of mixxx's more advanced mapping capabilities (outside of the point-and-click mapping wizard), they already have to learn JS, read 5 long wiki pages, etc. The little effort it takes to learn how to change an applications environment variables is minuscule compared to that.

If we want to find a middle ground, I suggest we add a couple lines to the commandline parser that catches the --controllerDebug flag and then prints something along the lines controllerDebug is retired, start mixxx with this environmentvariable instead: QT_LOGGING_RULES="controller.*.debug=true;"

@Be-ing
Copy link
Contributor Author

Be-ing commented Oct 30, 2021

This PR is still ready to merge as-is.

@Holzhaus
Copy link
Member

Holzhaus commented Oct 30, 2021

I don't get really why it's such a problem to use QLoggingCategory::setFilterRules to enable controller debug output when that flag is given (for a grace period, e. g. until 2.5). This would make life easier for a lot of Windows users that are not power users.

But for me, it's also okay to merge without that. This can easily be implemented later. No reason to block this change.

@Be-ing
Copy link
Contributor Author

Be-ing commented Oct 30, 2021

I don't get why we should add a hack for hypothetical developers who could easily use the new way.

@Be-ing
Copy link
Contributor Author

Be-ing commented Oct 30, 2021

Because the rest of Mixxx doesn't use categorized logging yet, a --controller-debug hack can't work the way it did before. It would only be able to turn on controller debug logging without --log-level debug, but --log-level debug now turns on controller debug logging if you don't set the Qt filter rules. So I think it would be extra pointless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants