Recently I needed to troubleshoot kernel responses and found it helpful
to distinguish status types (busy vs. idle) - thought others might find
it useful as well.
Entries that previously appeared as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status
```
will now appear as...
```
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (busy)
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_input
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: display_data
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: execute_result
activity on 33383dcc-c054-4dc0-b842-16063ea160fe: status (idle)
```
Then split the file into two files, one containing the metrics themselves, the other containing any function that have something to do with prometheus.
Finally, Added new metrics into the prometheus.metrics file that represent the number of running terminals and added the functionality for that metric to be recorded in the terminal.api_handlers file.
It's still (IMHO) unclear how the adaptation goes. Like does "adapting
to protocol X.Y.Z." mean the end-result is X.Y.Z or what you
got is X.Y.Z and it's X.Y.W after adaptation.
Although I'm unable to reproduce the issue, its a safe change to
prevent an AttributeError from occuring ('NoneType' object has no
attribute 'close'). The user that reported this is attempting to
launch a kernel and I believe the launch only partially completed
such that `kernel._activity_stream` did not get established.
(This occurred from Jupyter Enterprise Gateway where we deal with remote
kernel launches across resource-managed clusters, so things are a bit
more involved relative to kernel establishment.)
- Improves understanding (French contains « Sauvegarder » and « Enregistrer »,
which have different meaning, let's take advantage of that).
- Fix layout (too long sentences were breaking CSS layout in some cases)
`exporter_map` is deprecated, so let's use the list of exporters fetched
from the installed entrypoints.
There's a supposed attribute `export_from_notebook` that should be set
to a friendly string name if the exporter should be exposed in the
front-end. However, the exporters defined in `nbconvert` don't have it
set, so I haven't used it to determine inclusion in the list. Instead,
I've used the entrypoint name as the friendly name, which looks like it
was the intention from the way they are named.
I ran the unit tests and tried starting up the notebook server and
accessing the API endpoint to verify the JSON looked correct.
Dmitry Mikushin
Min RK
Mathis Hammel
1kastner
Kevin Bates
Steven Silvester
Maxim Vov
Arjun Radhakrishna
Matthias Bussonnier
Gustavo Efeiche
Jocelyn Delalande
Kristian Gregorius Hustad
Bill Major
Sally Wilsak
Peter Parente
Félix-Antoine Fortin
Dave Aitken
Maitiu O Ciarain