PR: Disable AppNap

[impact27]

solves ipython/ipython#11602

This is caused by AppNap: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap.html
This can be desactivated by https://pypi.org/project/appnope/

[ccordoba12]

This could be done only at the event loops level and not for the entire application. At least that's how it was done in old IPython versions:

https://github.com/ipython/ipython/blob/a2685d78f2403f84e6cb915ae11a4f6033ccc5f6/IPython/lib/inputhook.py

[impact27]

I disagree, the problem here is not limited to the back ends. If the user creates a gui app (qt5 / cocoa/ ...), macos will reclassify the kernel as a GUI application. Therefore, If the kernel (which is not a GUI application intrinsically) shows any window at any point, then macos will start to slow it down. Therefore AppNap should not apply to ipykernel. (As AppNap uses window usage as a way to know if the app is used, which is not at all a good indicator in the case of ipykernel.)

[impact27]

I am not sure what the error is. I see the error intermittently in spyder-kernels tests as well.
in with setup_kernel(cmd) as client:, somehow the connection file is empty? json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

[impact27]

Retriggering the tests

[ccordoba12]

@impact27, you should really avoid your practice of mixing PRs because it makes reviewing them a nightmare.

So please remove your last commit here and in PRs #438 and #439, and instead please try to make PR #445 pass, so it can be merged first.

[impact27]

@impact27, you should really avoid your practice of mixing PRs because it makes reviewing them a nightmare.

So please remove your last commit here and in PRs #438 and #439, and instead please try to make PR #445 pass, so it can be merged first.

I am sorry that this makes it hard for you to review. It is my fault for merging the PRs before #445 was ready.

I will mark all the PR that depends on another PR as [Waiting depencency merge] so you know that they must not be reviewed before the dependent PR is merged.

[impact27]

The reason why I need to merge #445in the other PR is that AppVeyor gets stuck if #445 is not merged, so instead of having test suceeding in 10 min, there is failing tests in 3h.

[ccordoba12]

If the user creates a gui app (qt5 / cocoa/ ...), macos will reclassify the kernel as a GUI application

Even if there you haven't run %gui qt5 before creating the app?

[impact27]

I was able to trigger the problem purely with pyqt5

[impact27]

#!/usr/bin/env python3

import time
# Uncomment either
from PySide2 import QtWidgets, QtCore
# from PyQt5 import QtWidgets, QtCore

app = QtWidgets.QApplication([''])
timer = QtCore.QTimer(app)
timer.setSingleShot(True)
timer.timeout.connect(lambda: app.quit())
timer.start(35000)
app.exec_()
start = time.time()
time.sleep(0.0005)
print('dt = ', time.time() - start)

[ccordoba12]

I was able to trigger the problem purely with pyqt5

Ok, if that's the case then this should be merged as it is.

[ccordoba12]

Thanks @impact27 for finding the cause of this very annoying bug!

@blink1073, I think this one is ready.

[blink1073]

Thanks!