Failed to connect to Jupyter notebook when xeus-cling is installed as a kernel

[the0demiurge]

Bug: Notebook Editor, Interactive Window, Python Editor cells

Steps to cause the bug to occur

1. Run selection/line in python interactive window

Actual & Expected behavior

Your Jupyter and/or Python environment

Please provide as much info as you readily know

• Jupyter server running: Local
• Extension version: 2019.9.34911
• VS Code version: 1.38.1-1
• Setting python.jediEnabled: true
• Python and/or Anaconda version: Python 3.7.4
  conda 4.7.11
  jupyter notebook --version 6.0.1
• OS: Arch Linux x86_64
• Virtual environment: conda

Developer Tools Console Output

 Info Python Extension: 2019-09-24 13:29:14: Request for tmlanguage file.

webviewElement.ts:296 [Embedded Page] 
Could not create web worker(s). Falling back to loading web worker code in main thread, which might cause UI freezes. Please see https://github.com/Microsoft/monaco-editor#faq

webviewElement.ts:296 [Embedded Page] 
Failed to construct 'Worker': Script at 'vscode-resource:/home/charles/.vscode/extensions/ms-python.python-2019.9.34911/out/datascience-ui/history-react/editor.worker.js' cannot be accessed from origin 'null'.

[rchiodo]

The web worker messages are expected. They have no impact on running a cell.

However your jupyter might be spewing extra output that's messing up our parsing.

Can you run 'python -m jupyter notebook --version' and respond with the results?

[rchiodo]

Or even better if you could go to 'Help | Toggle Developer Tools', click on the console tab, right click and save as, and upload the log file. Thanks.

[the0demiurge]

jupyter notebook --version 6.0.1

Here is the log file:
vscode.log

[rchiodo]

From your log it looks like we find jupyter, but we can't enumerate the kernel specs you have installed. It never finishes.

What do you get if you do this:
python -m jupyter kernelspec list

[the0demiurge]

Available kernels:
  python3    /home/charles/miniconda3/share/jupyter/kernels/python3
  xcpp11     /home/charles/miniconda3/share/jupyter/kernels/xcpp11
  xcpp14     /home/charles/miniconda3/share/jupyter/kernels/xcpp14
  xcpp17     /home/charles/miniconda3/share/jupyter/kernels/xcpp17

[rchiodo]

Hmm. I installed those kernels and it still works for me. I think the only way forward would be for us to add more logging and then have you try again.

[the0demiurge]

vscode.log
Here is some new log:

[Extension Host] Info Python Extension: 2019-09-27 10:43:43: Cached data exists getEnvironmentVariables, <No Resource>
2console.ts:137 [Extension Host] Info Python Extension: 2019-09-27 10:43:43: > ~/miniconda3/bin/xcpp ~/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/interpreterInfo.py
console.ts:137 [Extension Host] Info Python Extension: 2019-09-27 10:43:43: Cached data exists getEnvironmentVariables, <No Resource>
2console.ts:137 [Extension Host] Info Python Extension: 2019-09-27 10:43:43: > ~/miniconda3/bin/xcpp ~/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/interpreterInfo.py
console.ts:137 [Extension Host] Info Python Extension: 2019-09-27 10:43:43: Cached data exists getEnvironmentVariables, <No Resource>
2console.ts:137 [Extension Host] Info Python Extension: 2019-09-27 10:43:44: > ~/miniconda3/bin/xcpp ~/.vscode/extensions/ms-python.python-2019.9.34911/pythonFiles/interpreterInfo.py

It seems jupyter uses xcpp rather than python kernel, maybe this plugin needs a kernel selection option, and auto select python as default :)

[rchiodo]

Hmm. Not sure why it's picking your kernel instead. It's supposed to only pick python kernels. (There's a backlog item to allow kernel picking, we just haven't gotten to it yet)

What does the json for your python kernel look like? (It should be a file under /home/charles/miniconda3/share/jupyter/kernels/python3)

There might be a problem with path matching that's preventing us from figuring out it's the python kernel.

Additionally I did add a bunch more logging to our kernel enumeration. If you install the insider's build of the extension, it should generate more info around kernel spec enumeration.

[the0demiurge]

python kernel.json:

{
 "argv": [
  "/home/charles/miniconda3/bin/python",
  "-m",
  "ipykernel_launcher",
  "-f",
  "{connection_file}"
 ],
 "display_name": "Python 3",
 "language": "python"
}

The logs is here:
vscode..log

[rchiodo]

@the0demiurge can you print out your other kernel specs? I'm guessing we're picking up the path in those files and trying to see if they're a python interpreter or not. That call may never be returning.

[rchiodo]

Or it might be a conda environment that's configured to use xcpp somehow. The code I think that's failing is this:
https://github.com/microsoft/vscode-python/blob/147d49da6bfba6fd620a7d05c08437fcd95d54c7/src/client/common/process/pythonProcess.ts#L31

[rchiodo]

That code is using xcpp to try and run a python file. Somehow we think /miniconda/bin/xcpp is a python path.

[rchiodo]

Yeah that's likely the problem. I get this if I run xcpp by itself and it sits there waiting.

Starting xeus-cling kernel...

If you want to connect to this kernel from an other client, just copy and paste the following content inside of a `kernel.json` file. And then run for example:

# jupyter console --existing kernel.json

kernel.json
{
    "transport": "tcp",
    "ip": "127.0.0.1",
    "control_port": 59315,
    "shell_port": 59829,
    "stdin_port": 54616,
    "iopub_port": 64352,
    "hb_port": 50043,
    "signature_scheme": "hmac-sha256",
    "key": "5824dde9194d41b88b92e8847746411e"
}
Run with XEUS 0.21.1

[rchiodo]

I'm going to add a timeout into our interpreter path checker.

[rchiodo]

I added a timeout to where I think the problem is. Our next insider's build should have the fix for this, assuming the insider's build generates. It should be build 40512 or higher to have this fix.

[the0demiurge]

This worked! Thank you!