exponentially decay message frequency in live_info

This way, you would not have to wait for all messages to be displayed after you open your laptop in the morning when you run an simulation overnight on the cluster.

notice this is a proof of concept, the randomness is not really important, but could be removed with if we keep track of the last printed message. Also it depends on status.comm.kernel.iopub_thread._events which I suppose is meant for internal usage (indicated by the underscore before _events.

Both these should be possible to mitigate when more time is spend on those parts.

added 49 commits

• ae3870e1...c816cf67 - 48 commits from branch master
• 67b36ce4 - exponentially decay message frequency in live_info

Compare with previous version

added 1 commit

• e0468228 - exponentially decay message frequency in live_info

Compare with previous version

added 1 commit

• f96ee903 - exponentially decay message frequency in live_info

Compare with previous version

added 1 commit

• 3450c4fb - exponentially decay message frequency in live_info

Compare with previous version

added 1 commit

• a05abe81 - exponentially decay message frequency in live_info

Compare with previous version

unmarked as a Work In Progress

changed the description

@jbweston, @Jorn and I tested this just now and it seems to work just fine! The message queue never gets longer than ~10 messages.

We wrapped the body of should_update in a try except because we use a private API.

assigned to @jbweston

If I understand correctly what we want to achieve is to stop posting updates to the runner info when there is no client connected.

It would be preferable to find a way to do this without private API (we should ask on Gitter or sth about how to apply "backpressure" in ipykernel).

We should accept this change, as it does improve the user experience and the "ugliness" is hidden away in the implementation. Minimally I would like to see a test for the private API that we hit before I give a thumbs up (we will have to test specifically against the most recent version of ipykernel, and maybe master also, but this can be a separate MR.).

added 1 commit

• 40f48876 - test private attribute used in 'live_info'

Compare with previous version

removed assignee

marked as a Work In Progress

I've asked for some advice here.

added 53 commits

• 40f48876...6cdd24e9 - 51 commits from branch master
• 243561d6 - exponentially decay message frequency in live_info
• 7ec058c4 - test private attribute used in 'live_info'

Compare with previous version

added 1 commit

• 43d2b92a - test private attribute used in 'live_info'

Compare with previous version

unmarked as a Work In Progress

assigned to @jbweston

added 1 commit

• 7f936b7c - test private attribute used in 'live_info'

Compare with previous version

resolved all discussions

merged

mentioned in commit a6dae434

mentioned in issue #125 (closed)