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

Timestamped index to buffer #65

Open
jayvdb opened this issue Aug 26, 2019 · 3 comments
Open

Timestamped index to buffer #65

jayvdb opened this issue Aug 26, 2019 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@jayvdb
Copy link
Contributor

jayvdb commented Aug 26, 2019

#64 (comment) mentions merging stdout and stderr to reflect that both typically appear on the same user console, interleaved.

Another similar feature is timestamping the activity occurring on the "console", so those timestamps can be shown to the user, or timing info used in test logic.

@bskinn bskinn added the enhancement New feature or request label Aug 26, 2019
@bskinn bskinn added this to the Sooner milestone Aug 26, 2019
@bskinn
Copy link
Owner

bskinn commented Aug 26, 2019

Would this make more sense as a logging feature, tied/related to #43?

I guess the logging would derive from some sort of (timestamp, message) semantic structure to the content that's handled by the mocked stdfoos, though -- no reason not to expose that structure through the API in some fashion.

@jayvdb
Copy link
Contributor Author

jayvdb commented Aug 26, 2019

I've tried tightly coupling stdio with logging once before, in pywikibot, and it is working there (or was last I looked, but I am not active there for over a year). It has some pleasing benefits, like this feature being 'free', but it required some nasty initialisation sequences. I suspect that it might be less troublesome here when there isnt a real console attached, and also require less hacks because of no py2 support. Worth trying again; I'll do a POC based on pywikibot and we can evaluate it.

@bskinn
Copy link
Owner

bskinn commented Aug 26, 2019

Seems to me the "easiest" way to do it is to have the streams actually represented by an underlying list of ~annotated chunks of text, as was done with one of the entities over at coala-utils. The stream behaviors would then have to be implemented as an interface layer over this data structure.

Logging could then occur around the various interactions with the data structure... read/write/etc.

I think dealing with arbitrary seeks within a given "message unit" could be hairy, if such were desired to be implemented, though.

@bskinn bskinn mentioned this issue Sep 16, 2019
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants