Configurable sleeps
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 391
- Forks
- 69
- Avg merge
- 1d 34m
- Merged PRs (30d)
- 2
Description
Hi, I was integrating rexpect into a project and found that the sleeps are longer than what we needed. Specifically the sleep in read_until is 100ms, and I found that decreasing this to 5ms sped up some of our tests that are using rexpect.
https://github.com/rust-cli/rexpect/blob/be7f1ab8147c3c17e0600e59d1f98d1963d2d880/src/reader.rs#L287
Of course I wouldn't suggest everyone using 5ms, so maybe there's room for configurability? For now I have a fork with that small change.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at src/reader.rs around the read_until sleep referenced in the issue, then trace how read_until is configured and called. Determine where a configurable delay belongs and verify that the default behavior remains unchanged while callers can use a shorter delay.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100