jiebi/CodeConvo huggingface dataset:
Code change:
confirmDeleteRunningCell: 'notebook.confirmDeleteRunningCell', remoteSaving: 'notebook.experimental.remoteSave', gotoSymbolsAllSymbols: 'notebook.gotoSymbols.showAllSymbols', <del> cellExecutionScroll: 'notebook.revealNextOnExecuteBehavior' </del> <ins> scrollToRevealCell: 'notebook.scrolling.revealCellBehavior', anchorToFocusedCell: 'notebook.scrolling.anchorToFocusedCell' </ins> } as const; export const enum CellStatusbarAlignment {

Related discussion:
text: a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.
Code change:
confirmDeleteRunningCell: 'notebook.confirmDeleteRunningCell', remoteSaving: 'notebook.experimental.remoteSave', gotoSymbolsAllSymbols: 'notebook.gotoSymbols.showAllSymbols', <del> cellExecutionScroll: 'notebook.revealNextOnExecuteBehavior' </del> <ins> scrollToRevealCell: 'notebook.scrolling.revealCellBehavior', anchorToFocusedCell: 'notebook.scrolling.anchorToFocusedCell' </ins> } as const; export const enum CellStatusbarAlignment {

Related discussion:
text: I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by
Code change:
confirmDeleteRunningCell: 'notebook.confirmDeleteRunningCell', remoteSaving: 'notebook.experimental.remoteSave', gotoSymbolsAllSymbols: 'notebook.gotoSymbols.showAllSymbols', <del> cellExecutionScroll: 'notebook.revealNextOnExecuteBehavior' </del> <ins> scrollToRevealCell: 'notebook.scrolling.revealCellBehavior', anchorToFocusedCell: 'notebook.scrolling.anchorToFocusedCell' </ins> } as const; export const enum CellStatusbarAlignment {

Related discussion:
text: Currently the scroll top position update is not context-aware, meaning when we have cell height changes, we don't know if it's because output height change, or users re-run a cell and outputs are updated/replaced, or users shift+enter to run cell and navigate to next cell. Users might have different expectations for each scenario but currently our heuristics for updating the scroll top didn't take the context into account. Let's use this issue to finalize the desired behavior of scroll top update. The polished/new design should cover [ ] Update element height API respects context (execution, execute+create, output update) [ ] Reveal API should handle out of sync view/content height Click the run button or press Ctrl+Enter to run focused cell If there is no enough room/space after the cell (e.g., the focused cell is the last cell) Users have disabled [ ] There is no output before execution, the view should scroll up to reveal the output fully [ ] Some users might want the bottom of the output to be fully revealed, when the output is larger than the viewport [ ] There is output before execution, the cell position should be persistent Users have enabled [ ] Reveal cell output If there is enough room after the cell [ ] Reveal cell output [ ] If the cell input is larger than the viewport, execute cell should reveal the output properly [ ] Collapse focused cell output should always keep the cell in viewport [ ] Type/Pasting content into focused cell should keep the cell in viewport [x] [ ] Notebook cell list reveal api might reveal a position on a cell whose view height is not synced with real editor height yet. [ ] Execute non-focused cell, should it keep the focused cell position persistent or keep the top of the target cell persistent? [ ] Non focused cell output height change should not change scroll top on scroll [ ] Shift+enter executes and moves focus to next cell, then new focused cell should always be in viewport [x] Scroll top position of inactive notebook editor should not change if the first partially visible cell's height change
I noticed an issue recently, is this related? Paste a large amount of text into a code cell The notebook scrolls down so far that the focused code cell is out of the viewport I can open a separate issue if you want
I guess what you were seeing is , I'll update the description to include this.
Couple cases discovered in the latest notebook sync.
Code change:
confirmDeleteRunningCell: 'notebook.confirmDeleteRunningCell', remoteSaving: 'notebook.experimental.remoteSave', gotoSymbolsAllSymbols: 'notebook.gotoSymbols.showAllSymbols', <del> cellExecutionScroll: 'notebook.revealNextOnExecuteBehavior' </del> <ins> scrollToRevealCell: 'notebook.scrolling.revealCellBehavior', anchorToFocusedCell: 'notebook.scrolling.anchorToFocusedCell' </ins> } as const; export const enum CellStatusbarAlignment {

Related discussion:
text: both of these are likely tied to outputLineLimit being large @ 100 when the shift-enter behavior is set to "firstline" the events are as follows: first line of next cell is focused and shown at the bottom of the viewport output is cleared and the focused cell is pulled upwards against the currently executing cell output streams and pushes the focused cell out of the viewport. my ideal thoughts: anchor the focused cell (with setting), maintaining the first line visible. output will stream in, pushing the executing cell upwards out of the viewport shift-enter set to "fullCell" and next cell has a large output focus shifts to next cell, and the viewport exposes the bottom of the output for that cell. there is no cell editor in the viewport my thoughts: "fullCell" behavior should show the top of the next cell editor at the top of the viewport
Code change:
} private writeNotice(terminal: IDetachedTerminalInstance, str: string) { <del> terminal.xterm.write(`x1b[2m${str}x1b[0m`); </del> <ins> terminal.xterm.write(formatMessageForTerminal(str)); </ins> } private attachTerminalToDom(terminal: IDetachedTerminalInstance) {

Related discussion:
text: This: Now results in 1/2 the minimum contrast requirements which is a soft accessibility issue. It seems like these messages are special vscode messages which use special formatting in the real terminal:
Code change:
} private writeNotice(terminal: IDetachedTerminalInstance, str: string) { <del> terminal.xterm.write(`x1b[2m${str}x1b[0m`); </del> <ins> terminal.xterm.write(formatMessageForTerminal(str)); </ins> } private attachTerminalToDom(terminal: IDetachedTerminalInstance) {

Related discussion:
text: There's no separator line between the two components. !
Seeing the seperator: <img width="69" alt="image" src=""
Code change:
margin-top: -1px; } <ins> .codicon-debug-breakpoint.codicon-debug-stackframe-focused::after, .codicon-debug-breakpoint.codicon-debug-stackframe::after { content: 'eb8a'; position: absolute; } </ins> .monaco-editor .debug-top-stack-frame-column { font: normal normal normal 16px/1 codicon; text-rendering: auto;

Related discussion:
text: ! It could be that I caused this, but I doubt it (injected text has nothing to do with the gutter, maybe they shared a CSS rule).
I can reproduce but I'm not aware of any changes in that area from the debug side.
I would like to work on this issue!
Before fixing anything we should do a "git bisect" to find the commit that broke this.
commit . it should
thanks for pointing out the commit! If you like, you can provide a PR, that would be awesome!
PR
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> import { MarshalledObject } from 'vs/base/common/marshalling'; import { MarshalledId } from 'vs/base/common/marshallingIds'; import { URI, UriComponents } from 'vs/base/common/uri';

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.62.3 (Universal) Jupyter Extension version (available under the Extensions sidebar): v2021.10. Python Extension version (available under the Extensions sidebar): v2021.11. OS (Windows Linux distro) and version: Mac Python and/or Anaconda version: 3.7.12 Type of virtual environment used (N/A ...): conda Jupyter server running: Remote I expect code cells to begin executing immediately and (for simple code snippets) to finish executing immediately (e.g. print('hello')) Once the jupyter notebook starts to contain a non-trivial amount of stuff, I start to observe the following behaviors: (1) code cells that contain simple tasks (e.g. ) start taking several seconds or more to complete, (2) it may take several seconds or even minutes for vscode to even visually show that it will start executing a code cell, and (3) in severe cases, the whole vscode editor will become unresponsive and I will need to force shut it down. Below is code for a jupyter notebook that contains a minimal example. The problems start to appear once you've cycled through the code cells 2 or 3 times. I think one of the main contributing factors to this issue are just notebooks that have a lot of "stuff" in them. To demonstrate that, the last code block prints 50 scatter plots as pngs, which the native jupyter lab server over the browser handles just fine... but vscode seems to have issues. Moreover, in this simple example I have observed instances where it starts to take a while to save the notebook and the editor may even become unresponsive. Other things to note: I am running this jupyter notebook on an AWS EC2 instance with ~90GB memory 48 CPUs (using a AWS linux ami: ). I have not yet observed these same issues when I have the kernel running on my local mac machine. <details<summaryJupyter example </summary<p</p</detailsHere is a screenshot where it takes almost 3 seconds for a simple print statement. I've seen worse in some of my code related to real projects, though. This is just what I was able to reproduce with a minimal example.
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> import { MarshalledObject } from 'vs/base/common/marshalling'; import { MarshalledId } from 'vs/base/common/marshallingIds'; import { URI, UriComponents } from 'vs/base/common/uri';

Related discussion:
text: <img width="1593" alt="Screen Shot 2021-11-22 at 4 48 27 PM" src="https://user-"
Thanks for filing this issue & I'm sorry you're running into this issue, please could you try the following: Check the performance withouth any data frames in the outputs You can run most of the same cells, but not display the outputs (e.g. don't run the cells with ) I'd like to check whether the perf is a result of large outputs. If that doesn't make any difference please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Try the same thing & provide the logs from the output panel (use the command to get to the output panel)
Thanks . Not displaying large amounts of output does help. I experimented with the code a bit and here are my observations: (1) If I disable the cell with just the statement (but still outputting the figures), while it helps a little, I still see a significant slowdown. In particular, once I execute the code block that prints the figures (see below) and it is done, I try to execute the first code block again (containing the import statements), but there is a good 30-60 second delay until it will start to executing. (2) If I still create the figures but no longer display them (see below), this helps immensely with performance... there are basically no issues. (3) While still hiding the figures as in (2), but I go back to displaying and increasing the number of columns and rows of that are display to 200 (see below), then there is small decrease in performance. (4) If I do the same as (3), but take it even further by displaying 500 rows and columns of , then performance significantly degrades (see the screenshot). Once it was done displaying , it took ~19 seconds for a print statement, ~35 seconds to make the figures (normally takes a ~3-5 seconds), and it took over a minute to execute that last empty cell (the execution time was hidden once it was done). <img width="1585" alt="Screen Shot 2021-11-23 at 10 14 06 AM" src="https://user-"
Thanks for the feedback.
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> import { MarshalledObject } from 'vs/base/common/marshalling'; import { MarshalledId } from 'vs/base/common/marshallingIds'; import { URI, UriComponents } from 'vs/base/common/uri';

Related discussion:
text: Please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Run the command An editor will be opened with some text such as , please copy all of that & paste that into this issue Try simple print statements (without any data frames, and figures, lets keep it very simple) Please ensure the notebook is empty & does not contain any outputs only 1-2 cells with simple print statements. Provide the logs from the output panel (use the command to get to the output panel) Reload VS Code Repeat what you did earlier Provide the logs from the output panel (use the command to get to the output panel) Please note, I'll need two logs, one without any data frames, no plots, just print statements. The other is the one with dataframes and the like.
Here is the text for : Even if vscode totally froze up while trying to run something in jupyter, I was still always able to ssh into the server no problem. Here is the Jupyter output from just the print statements: <details<summaryLog</summary</detailsHere is the Jupyter output where I print large dataframes and plots: <details<summaryLog</summary</detailsFew other things I've observed: (1) In the second log above, I see there are some lines like in it, but I was not always able to reproduce that output. (2) Here are some additional logs that I observed while it took 15 minutes to execute a cell with a simple print statement (but it was executed after cells with the dataframes and plots): <details<summaryLog from </summary</details<details<summaryLog from </summary</details
Thanks for the logs. Transferring to VS Code due to connectivity issues with remtoe SSH
Also having this issue with jupyter over ssh, in a notebook that has a decent number of plots.
This issue happened with me also (especially when i am insider a docker container inside the remote machine)
I have the same issue, even when I freshly open a notebook with some outputs it is very slow and unresponsive. <img width="273" alt="image" src="https://user-"I have a stable connection to the server: !
Same problem, sometimes it works fine, sometimes it is unusable, stable and insider !
After discussion in sync.
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> import { MarshalledObject } from 'vs/base/common/marshalling'; import { MarshalledId } from 'vs/base/common/marshallingIds'; import { URI, UriComponents } from 'vs/base/common/uri';

Related discussion:
text: Possibly add logging for every message that's only turned on if the user explicitly is told to (for debugging purposes).
experiencing similar issues when working on jupyter via ssh to an ubuntu server from an ubuntu pc
ALso had the issue where running a cell lags(or starts after some time) for jupyter notebooks when using remote SSH aws azure
Still the same problem
I also experience the same. I observed that: It happens with Jupyter notebooks, but not in the Interactive window. It does not happen if you connect to a Jupyter kernel that is not managed by VScode. It happens when your notebooks has many figures. I hope these may help diagnose the problem.
Same here..
As an additional info to what enlightened us. Jupyter execution on remote ssh machine slows down (i.e., gets stuck) when notebook size is large (64 MB). VS code executing notebook cell normally for smaller sized (ie., 1MB ) notebook
Would it be possible to share such a notebook? Is the size 64 MB with or without ouput in the notebook? If its a large file you could optionally email it to one of us (us = Microsoft maintainers of VS Code)
sorry that is confidential work for the time being.
Experiencing the same issue as well. Networking is not a problem since I connect to the notebook's machine on a local network
I've also been having this issue lately although I think it only happens in certain circumstances. I can't share the notebook I'm working with at the moment as it's private (sorry!), but it does have many matplotlib figure outputs and dataframe outputs. The notebook itself is only 3.6 MB in size. I'm running the notebook on a Linux server with Python 3.9.7, specifically I'm connecting to the machine remotely with "Connect to Host" to edit and run code on the server remotely. Latest version of VS Code and all extensions, connecting from a machine running Windows 11. It seems connecting on the same network as the machine with my Linux laptop doesn't result in any issues, and I haven't noticed any problems with running the notebook from there. However, connecting from a different network when working from home causes the same notebook to be very laggy, including lagging for 30+ seconds on simple code cells containing e.g. just a print statement.
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> import { MarshalledObject } from 'vs/base/common/marshalling'; import { MarshalledId } from 'vs/base/common/marshallingIds'; import { URI, UriComponents } from 'vs/base/common/uri';

Related discussion:
text: I don't see how network speed/my connection to the server from home could be the issue (12ms ping, ~5 Mbps upload / ~50 Mbps download connections). Maybe there's something in the different OSes having different results, could also be unrelated though. I should try connecting with a Linux machine not on the same network and see if I can reproduce the results.
Same problem here, just a correction it is not dependent on the figure number or commands difficulty, will take to execute 30 to 40s, and yes with a separate instance of Jupyter Lab server (not managed by VScode). Directly connecting to Jupyterlab over ssh port forwarding order of magnitude faster. Workflow: Windows to Linux remote SSH (cluster) Another instance in the cluster used to set up JupyterLab instance Change Jupyter server to remote of the previously created instance execution super slow (even delay between starting and finishing) ~ 30 second delay followed up by ~ 40 s execution Connecting directly from Windows tunnel to JupyterLab ~ few seconds execution Note: Both the Jupyter Lab instance and the initial remote ssh share access to the file system, just different hardware. Also after changing to remote, some shenanigans happen with the vscode, unable to open files, etc, had to restart everything to make it work again.
I've had the same issue with VScode and Jupyter - notebooks becoming unresponsive after a few cells are used. The console shows continuous (every 20 seconds) reconnecting. with the level set to "trace". I can share a relevant file if it is helpful.
I've had the same slow issue with VScode and Jupyter when connecting to a remote docker container via ssh, and I've also observed that keeps producing tremendous streams
If someone can share a notebook that triggers this issue (lots of outputs, graphs with lots of data, etc?) that would be helpful, thanks
I noticed that if I switch the format from svg to png (by changing the setting ), the notebook would run smoother.