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

The logic to handle test hanging is flaky #38

Closed
oliverhu opened this issue Jan 26, 2017 · 5 comments
Closed

The logic to handle test hanging is flaky #38

oliverhu opened this issue Jan 26, 2017 · 5 comments
Assignees

Comments

@oliverhu
Copy link
Member

We were trying to address issue #12 - [self.device terminateApplicationWithID:self.hostBundleId error:&error]; in SimulatorMonitor.m doesn't work in iOS 10.2 runtime. in PR #19 , however, it is still flaky, seeing hangings sometimes.

Initial inspection is that - the SimulatorRunner may be nil. Assigned to @vargon to take a look

@oliverhu oliverhu added the bug label Jan 26, 2017
vargon added a commit that referenced this issue Jan 27, 2017
- Ensure the runner remains around for the lifetime of the launch application block
- Add more logging around killing the app in the simulator in case the above fix doesn't do anything
vargon added a commit that referenced this issue Jan 27, 2017
- Ensure the runner remains around for the lifetime of the launch application block
- Add more logging around killing the app in the simulator in case the above fix doesn't do anything
@ob
Copy link
Member

ob commented Feb 1, 2017

Why is the same commit twice in this PR?

@vargon
Copy link
Contributor

vargon commented Feb 1, 2017

I think it's just a github thing. I created issue #40 with my branch which referenced this issue, plus my comment for the commit referenced this issue.

@ob
Copy link
Member

ob commented Feb 7, 2017

Fixed by #49

@ob ob closed this as completed Feb 7, 2017
@oliverhu
Copy link
Member Author

We can still reproduce this, we are not actually handling timeout tests properly

@oliverhu
Copy link
Member Author

fixed again in #80

RainNapper pushed a commit to RainNapper/bluepill that referenced this issue Jun 16, 2021
PythonExternalLinter is a new abstract base class for external
Python-based linters. It introduces support for virtualenv-based tool
installations. If a known virtualenv is found in the project root, and
the linter binary can be found within it, then that path will be used to
execute the linter. Otherwise, the linter binary is assumed to be in the
$PATH.

The list of known virtualenvs defaults to `.venv` but can be changed
using the `python.virtualenvs` configuration key.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants