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

make AndroidLogStreamBuffer print to console aswell #98

Closed
wants to merge 0 commits into from
Closed

make AndroidLogStreamBuffer print to console aswell #98

wants to merge 0 commits into from

Conversation

mgood7123
Copy link

this is useful when executing native executables via a shell

@codecov-commenter
Copy link

codecov-commenter commented Jul 22, 2020

Codecov Report

Merging #98 (95cea30) into master (37df9bc) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #98   +/-   ##
=======================================
  Coverage   97.64%   97.64%           
=======================================
  Files          98       98           
  Lines        7012     7012           
=======================================
  Hits         6847     6847           
  Misses        165      165           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 37df9bc...dd49ddd. Read the comment docs.

Copy link
Owner

@mosra mosra left a comment

Choose a reason for hiding this comment

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

Hmm, I'm not sure about the use case here -- usually what I have is either a console application, running in a shell (and then I don't need it to fill the android log because I see the output right away), or I have an APK, which doesn't make sense to be run from a shell anyway, and thus filling cout is wasteful as well.

Unless I missed something, it doesn't look to me like a single app would need both at the same time -- and if it can operate in both contexts, I could imagine it only opting-in to AndroidLogStreamBuffer if it's not run from a shell.

Furthermore, this doesn't really need a change to this class itself. It could easily be done in a subclass that overrides the sync() and then prints to both -- so this means you could easily make a subclass inside your particular poject that has such special needs.

src/Corrade/Utility/AndroidLogStreamBuffer.cpp Outdated Show resolved Hide resolved
const char * tag = _tag.data();
const char * data = str().data();
__android_log_write(std::int32_t(_priority), tag, data);
std::cout << data;

Copy link
Owner

Choose a reason for hiding this comment

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

This causes all output to be put into std::cout, with no chance of distincting between stdout or stderr. I'm not sure I like that. Make this configurable? Or choose it based on _priority?

Also, what about flushing? Usually when you have error or assertion messages, you'd want them to be printed right away and not in some buffer that might not get emptied before the application crashes / aborts.

@mosra mosra added this to TODO in Utility via automation Jul 22, 2020
@mosra mosra added this to the 2020.0b milestone Jul 22, 2020
@mgood7123
Copy link
Author

Hmm, I'm not sure about the use case here -- usually what I have is either a console application, running in a shell (and then I don't need it to fill the android log because I see the output right away), or I have an APK, which doesn't make sense to be run from a shell anyway, and thus filling cout is wasteful as well.

Unless I missed something, it doesn't look to me like a single app would need both at the same time -- and if it can operate in both contexts, I could imagine it only opting-in to AndroidLogStreamBuffer if it's not run from a shell.

Furthermore, this doesn't really need a change to this class itself. It could easily be done in a subclass that overrides the sync() and then prints to both -- so this means you could easily make a subclass inside your particular poject that has such special needs.

hmmm ok

@mgood7123
Copy link
Author

how about this?

@mgood7123 mgood7123 closed this Mar 3, 2021
Utility automation moved this from TODO to Done Mar 3, 2021
@mosra mosra added the scrapped label Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Utility
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants