Closed p-i- closed 3 months ago
Sorry you are running into this and thanks for filing this issue I can see a few issues here
You seem to have some remote Jupyter Servers setup, if you are no longer using them, its best to delete them
Kernel Picker
select Jupyter Server
, and delete the items you are no longer using (invalid items are in your list and they seem to be timing out in attempts to connect to the server)x
icon (see images)2024-08-01 22:35:26.028 [warning] could not find a pixi interpreter for the interpreter at /Users/pi/code/2024/spins/.venv/bin/python This seems to be something from the Python extension, so lets leave that out for now.
AH -- at this point, after writing all of the above, it has finally stopped spinning & gives the correct ".venv (Python 3.12.3)".
Lets assume the kernel spinner is a non issue. i.e. lets assume this is always spinning, and you can ignore this.
But the problem you are still running into is the fact that the correct .venv
takes a while to appear, is that correct.
I'd like to separate the two, ie. the spinning icon could still appear whilst other kernels are being discovered, but in your case you want to see .venv
immediately.
Please can you confirm this.
Finally, please can you share the full logs, I'd like to see exactly whats going on and see whats slow. Thanks for this, however it doesn't show where the time was spent.
22:35:25.554 [debug] Start refreshing Kernel ~cker (1722548125554)
22:42:56.012 [debug] End refreshing Kernel ~cker (1722548125554)
Finally, please enable trace logging before sharing the logs again (again, please share the full logs) Please could you enable logging as follows:
Jupyter->Logging
trace
Jupyter
output panel (use the command Jupyter: Show Output
to get to the logs).I haven't been in this arc2/ folder for several vscode restarts now. Could be related?
Most likely due to the fact that you have some remote jupyter servers that are no longer available. However there are two issues here
.venv
takes a while to appear (this could be related to some delay in Python extension, lets first have a look at the Jupyter logs)@DonJayamanne Thankyou for your attention.
Just hover over the item and then click the x icon (see images)
I followed this instruction; there was indeed one item, which I deleted. I forgot to take a screenshot first, but I'm pretty sure it started with 10.3.... and was the http://10.3.0.1:6666/
visible in my prior log dump.
Restarting VSCode the issue is gone.
Unfortunately this does mean I can't collect logs that would indicate what is chewing up at the time. The previous log except that I posted WERE already at trace
level, however. Looks to me like VSCode is repeatedly timing out trying to connect to this rogue kernel.
Why do I even have such a rogue kernel? Last year I did some contract work in involving connecting to a client's remote machine, but I've been using VSCode ONLY for my own local Python projects this year.
Also, why did this problem just suddenly spring up today?
Yesterday I played with https://github.com/ConGustoAI/friendlly -- I've sent this thread to the author in case he can shine some light on this.
So, I'm now back to the original problem I was trying to fix before this issue: that if I create a fresh notebook and set a breakpoint and debug-run the cell, it appears to hang; it should reach the breakpoint and highlight that line red, but doesn't. I will file that as a separate issue.
One takeaway I can see from this is that it would be very nice if VSCode was more transparent about what's going on. I had to file an issue and follow an instruction to remove this timing-out kernel. it would have been nice to be able to see this information upon clicking the spinning kernel-picker icon. Maybe see a dropdown of kernels with a tick next to each item that has completed, and a spinner next to each item that hasn't.
Then I would naturally have observed that the currently selected kernel was FINE, but a rogue one was timing out, and would have investigated/removed the rogue one.
What actually happened is that I was experiencing a DIFFERENT problem (debugger-fail) together with THIS one (spinning), and looking at the logs saw TWO more potentially related symptoms:
1.
2024-08-01 22:35:26.028 [warning] could not find a pixi interpreter for the interpreter at /Users/pi/code/2024/spins/.venv/bin/python
2.
2024-08-01 22:35:26.856 [info] Starting Pylance language server. <-- last message
(for 2., I think it should either say "Pylance language server STARTED"
or there should be a subsequent message to that effect, otherwise it looks like the thing is hanging: I remember there were previous messages for another process that DID have separate messages for "Starting..." and "started!".
Just as a thought, wouldn't it help to have log messages hyperlink to knowledge-base articles? Some of your extensions have 5M+ downloads, which reflects a huge user base. I would imagine such a policy would significantly reduce the load on staffing issue tickets.
fwiw This is the problem I was actually trying to solve: https://github.com/microsoft/vscode-jupyter/issues/15914
Why do I even have such a rogue kernel? Last year I did some contract work in involving connecting to a client's remote machine, but I've been using VSCode ONLY for my own local Python projects this year.
Remote Jupyter servers used at any point are always linked to your user profile. Possible you never enabled symcing of profiles and you logged into your githu account or the like in VS Code just recently.
the original problem I was trying to fix before this issue: that if I create a fresh notebook and set a breakpoint and
Lets close in favour of #15914
] could not find a pixi interpreter for the interpreter at /Users/pi/code/2024/
This is caused by Python extension, see here https://github.com/microsoft/vscode-python/issues/23901
Wait, this is a completely separate issue AFAICS.
I fixed the spinning kernel-picker--icon by removing a rogue kernel.
I think this ticket is still actionable -- VSCode should indicate which kernel(s) are causing the spinning kernel-picker icon when you click on it, no?
i.e. I had to be told where to look to find this rogue kernel, which means many other users may experience the same frustration point.
The issue you've closed this in favour of is nothing to do with this issue. I know this because AFTER deleting the rogue kernel I restarted VSCode in a fresh folder, and STILL got the debugger-fail. That one's related to the non-default setting of JustMyCode
to off
(since restoring to default value fixes it).
PS Maybe remove the info-needed
tag?
i.e. I had to be told where to look to find this rogue kernel, which means many other users may experience the same frustration point.
The assumption is that if you have any remote kernels that you are no longer using then they'd be removed. I can leave this issue open as a feature request.
Type: Bug
Kernel-picker icon is spinning
Output -> Python:
^ Maybe this is the issue -- it never starts? I've tried reinstalling Jupyter and Pylance extensions, no luck.
Output -> Jupyter:
This all started because I was trying to set a breakpoint on a line of an .ipynb cell in another folder.
fwiw I'm seeing in same above log:
(hmm I don't have conda)
I haven't been in this arc2/ folder for several vscode restarts now. Could be related?
AH -- at this point, after writing all of the above, it has finally stopped spinning & gives the correct ".venv (Python 3.12.3)".
Here's the tail-end of the Output -> Jupyter:
And here's the tail-end of the Output -> Python:
(i.e. THAT hasn't changed, so looks like the Pylance was a red-herring)
One thing that still bugs me is:
(... in the Output -> Python) I don't know what this pixi thing is, and the message doesn't easily google. First hit goes to an issue that's an AB problem (user can't get Hello World working)
TLDR:
Please fix this. I've lost 2 hours restarting, reinstalling, digging thru logs, composing this.
fwiw I was able to execute a cell & get output before the picker stopped spinning.
Extension version: 2024.7.0 VS Code version: Code 1.92.0 (b1c0a14de1414fcdaa400695b4db1c0799bc3124, 2024-07-31T23:26:45.634Z) OS version: Darwin arm64 23.5.0 Modes:
System Info
|Item|Value| |---|---| |CPUs|Apple M2 (8 x 2400)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|2, 2, 2| |Memory (System)|24.00GB (0.64GB free)| |Process Argv|--crash-reporter-id f10d97cd-2115-4dba-a34a-07be9312995a| |Screen Reader|no| |VM|0%|
A/B Experiments
``` vsliv368cf:30146710 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes627:30244334 vscorecescf:30445987 vscod805cf:30301675 binariesv615:30325510 vsaa593cf:30376535 py29gd2263:31024239 vscaac:30438847 c4g48928:30535728 azure-dev_surveyone:30548225 2i9eh265:30646982 962ge761:30959799 pythongtdpath:30769146 welcomedialog:30910333 pythonnoceb:30805159 asynctok:30898717 pythonregdiag2:30936856 pythonmypyd1:30879173 2e7ec940:31000449 pythontbext0:30879054 accentitlementst:30995554 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 cppperfnew:31000557 dsvsc020:30976470 pythonait:31006305 dsvsc021:30996838 jg8ic977:31013176 pythoncenvpt:31062603 a69g1124:31058053 dvdeprecation:31068756 dwnewjupytercf:31046870 impr_priority:31102340 refactort:31108082 ccplc:31103425 pythonrstrctxt:31103193 wkspc-onlycs-c:31106320 wkspc-ranged-c:31107834 ```