Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching to a big notebook in a tab is slow #4292

Open
anshbansal opened this issue Apr 1, 2018 · 95 comments
Open

Switching to a big notebook in a tab is slow #4292

anshbansal opened this issue Apr 1, 2018 · 95 comments

Comments

@anshbansal
Copy link

@anshbansal anshbansal commented Apr 1, 2018

I am using Ctrl + Shift + ] to switch between tabs that I am using. It is slow when I am switching to a tab which is a jupyter notebook which is larger in size. I noticed that if I split my screen to have both already rendered then the switching is fast. This leads me to think that it is the browser rendering which is slowing things down. Not sure if this observation helps but maybe some form of caching rather than re-rendering the notebooks might make the switching faster?

@harpone
Copy link

@harpone harpone commented Apr 25, 2018

I have a habit of writing long notebooks with table of contents etc and I noticed the same issue... makes working with Jupyterlab quite cumbersome. FYI this does not happen with Jupyter Notebooks.

@sccolbert
Copy link
Contributor

@sccolbert sccolbert commented Apr 25, 2018

Are you using Firefox?

@anshbansal
Copy link
Author

@anshbansal anshbansal commented Apr 25, 2018

It is Google Chrome

@sccolbert
Copy link
Contributor

@sccolbert sccolbert commented Apr 25, 2018

Ok thanks. With regard to your comment about caching/re-rendering, unfortunately the browser doesn't give us that much control. We know we have a perf problem on FF due to how we're nesting flexboxes. We have plans to fix this for 1.0. Hopefully that corrects this issue as well.

@mladenj
Copy link

@mladenj mladenj commented Aug 16, 2018

same here,
JupyterLab 0.33.8 lagging when switching tabs,
but Jupyter Notebook 5.0.0 working without issues

Chrome, Version 68.0.3440.106 (Official Build) (64-bit)
Mac OS Sierra 10.13.1

@webermarcolivier
Copy link

@webermarcolivier webermarcolivier commented Sep 4, 2018

Same here.
I acknowledge that some of my notebooks are very large. Switching tabs take about 18 seconds. The same notebook switching on Jupyter Notebook 5.0 (regular Firefox tabs) is fast, although take a lot of memory.
Mozilla Firefox 61.0.1
Kubuntu 16.04

@YubinXie
Copy link

@YubinXie YubinXie commented Sep 4, 2018

Same here. Mac OS, Safari.
Switching one big notebook to another under same Jupyter lab page takes around 5 s. This 5 s really gives bad user experience.

@7kbird
Copy link

@7kbird 7kbird commented Sep 6, 2018

Same here,

  • JupyterLab 0.34.7
  • Chrome 68.0.3440.106 (64-bit)
  • Windows 10

@ian-r-rose ian-r-rose added this to the Future milestone Sep 6, 2018
@bjonen
Copy link

@bjonen bjonen commented Sep 12, 2018

Same problem on Windows with Chrome and Firefox. This really undermines the beautiful new feature of having everything in one browser window. Also reshuffling tabs that are large is suffering from this performance issue.

@eschersky
Copy link

@eschersky eschersky commented Sep 25, 2018

Same observation, for:
JupyterLab 0.34.9
Chrome Version 68.0.3440.106 (Official Build) (64-bit)
Windows 7

The notebooks I'm running are actualy not very big, about 1 to 2 MB, but still significant lags when switching between tabs.

@plubinski
Copy link

@plubinski plubinski commented Sep 28, 2018

I confirm the same problem. How to work with large files?

@ldanilov
Copy link

@ldanilov ldanilov commented Nov 6, 2018

Same on:

  • JupyterLab 0.35.2
  • Safari 12 and Chrome 70.0.3538.77 (Official Build) (64-bit)
  • OSX Mojave

I agree with all of the above. Due to performance issues I keep my usage of the JupyterLab feature set to the bare minimum to avoid any slowdowns. Really hoping 🙏 that this can and will be fixed.

This project and all the efforts which went into it is pure awesomeness.

@dmarienko
Copy link

@dmarienko dmarienko commented Jan 21, 2019

Hi, guys,
First I'd like to thank you all for your incredible work !!! That's really mind blowing tool !

I've just installed JupyterLab ver. 0.35.4 using pip and still observe slowness when switching between tabs under Win10, Chrome/Opera/FF. I see this issue is in the 'Future' milestone so as I understood it's still not in pypi repo, right ?

If so question is when it's planned to be pushed into 'production' ? We're considering to use JLab as replacement of classic Jupyter in our research work but this issue seems to be big stopper for us.

@maxwellmckinnon
Copy link

@maxwellmckinnon maxwellmckinnon commented Jan 30, 2019

@dmarienko Same issue on 0.35.4, both Chrome/Safari on a macbook here. Going to have to go back to notebook using the browser as tabs until switching performance can be addressed.

@oldgeeksguide
Copy link

@oldgeeksguide oldgeeksguide commented Feb 1, 2019

It's a particularly difficult issue to swallow because old jupyter doesn't seem to have this problem. I love most of the new features in jlab, but sometimes I go back to jupyter for practical reasons like this.

@vidartf
Copy link
Member

@vidartf vidartf commented Feb 5, 2019

The optimizations from #5700 are now in the 1.0.0 alpha prerelease. You can try it with pip install --pre jupyterlab. We'd love to hear back if people have any issues after this. Note, this:

  • does not improve the initial rendering of the notebook
  • does not improve rendering after resizing the notebook panel
  • does improve rendering when just switching between previously rendered tabs

Note: Replacing the Codemirror v5 with another editor (v6, monaco, ...) will be a more permanent solution, but hopefully this will be a decent band-aid in the meantime.

@AlexRig
Copy link

@AlexRig AlexRig commented Feb 9, 2019

The optimizations from #5700 are now in the 1.0.0 alpha prerelease. You can try it with pip install --pre jupyterlab. We'd love to hear back if people have any issues after this. Note, this:

  • does not improve the initial rendering of the notebook
  • does not improve rendering after resizing the notebook panel
  • does improve rendering when just switching between previously rendered tabs

Note: Replacing the Codemirror v5 with another editor (v6, monaco, ...) will be a more permanent solution, but hopefully this will be a decent band-aid in the meantime.

@vidartf do you recommend removing all traces of jupyterlab conda-forge before pip install --pre jupyterlab?

Note: Conda wouldn't allow pip install --pre jupyterlab with jupyterlab already present. I will attempt a remove before pip install --pre jupyterlab

@AlexRig
Copy link

@AlexRig AlexRig commented Feb 9, 2019

@vidartf I opened jupyter lab 1.0.0a1 in Conda with existing notebook panels and the problem persists. No cells were being executed.

Chrome 71.0.3578.98 (Official Build) (64-bit)
Windows 10

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 9, 2019

No cells were being executed.

Can you elaborate on 'no cells were being executed'? I thought this issue was about performance considerations in switching between tabs with long notebooks.

@AlexRig
Copy link

@AlexRig AlexRig commented Feb 9, 2019

That was just to say the kernal was idle and there was nothing running

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Feb 9, 2019

Ah, so you're saying that switching between tabs was still very slow, and you're adding that you weren't trying to execute code while you were doing it?

@AlexRig
Copy link

@AlexRig AlexRig commented Feb 9, 2019

Yes precisely, adding more colour.

@vidartf
Copy link
Member

@vidartf vidartf commented Feb 12, 2019

@AlexRig So you are saying that: With two tabs that were both previously displayed, and without any resizing, switching back and forth is still slow? Do you have linewrapping turned on or off for the cell editors?

@stefansimik
Copy link
Contributor

@stefansimik stefansimik commented Feb 15, 2019

The problem is really quite big.
If I open multiple tabs with bigger notebooks in Jupyter Lab,
switching is very very slow - takes from 5-15 seconds.
It is very uncomfortable to work with Jupyter Lab with such heavy lagging.

Really needs to be analyzed / fixed if possible.

(Anaconda Python v3.7, Jupyter Lab v0.34.9, Win10 latest, Chrome latest)

@renatoviolin
Copy link

@renatoviolin renatoviolin commented Feb 28, 2019

Using the Jupyterlab pre 1.0.0a1 and it is running faster than 0.35.4.
The differences I saw was the html render of some

that is being rendered different than the 0.35.4.
The overall performance to switch tabs has increased.

Running MacOS Mojave, Safari and Chrome (runs slightly faster on Chrome)

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Mar 6, 2019

Saw this issue in the wild this last week...

@dk1013
Copy link

@dk1013 dk1013 commented Jun 25, 2021

@sbowman-mitre
Thanks for the update. Can you provide more general info regarding your use case? Like do you have lots of plot visualisation, typically how many cells do you have in your notebook? I am using Jupyterlab v2, but I still feel the issue. (I typically have tens of figures and 100+ cells for a typical notebook.)

@sbowman-mitre
Copy link

@sbowman-mitre sbowman-mitre commented Jun 25, 2021

Thanks for the update. Can you provide more general info regarding your use case? Like do you have lots of plot visualisation, typically how many cells do you have in your notebook?

@dk1013 : yes, I build notebooks that include data loading & processing in python3 with pandas. Then my data visualizations use plotly. I typically have a dozen plots and dozens of cells. I don't keep track of memory, so not sure how large my footprint is when doing this stuff. But, I don't think this comparison is about how my notebooks are similar to yours (or others who find this thread). The point is that there is consistency across my notebook usage over time while the heavy lag in stitching tabs has gone away. So, at least for my typical notebook usage the problem is gone. If you haven't tried already, I recommend a full update to the latest version of Jupyter and all important packages.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jun 25, 2021

The other thing to try updating is your browser (or try a different browser). At times, for example, bugs in Firefox have made a dramatic difference in performance.

@mlucool
Copy link
Contributor

@mlucool mlucool commented Jun 25, 2021

For those commenting on slowness, it would be helpful to know:

  1. Size/shape of notebooks (e.g. # of cells, types of output)
  2. How long it takes to do the action which you perceive as slow (in s)

@afshin
Copy link
Member

@afshin afshin commented Jul 21, 2021

If you unzip this notebook and "Run All" cells, it will be about 9mb of text.: large.ipynb.zip

In JupyterLab 3.1.0rc1, it is noticeably slow when switching to this notebook tab or when closing a tab that results in switching to this notebook. It looks like this:

slow-switch-3 1

@mlucool
Copy link
Contributor

@mlucool mlucool commented Jul 21, 2021

Thanks for sharing @afshin. My quick test shows that the notebook you posted is being affected by #10046.

If you update print to printer then defined printer as:

from IPython.display import display
def printer(msg):
    display({"application/vnd.jupyter.stdout": msg}, raw=True)

The max output optimization can take effect.

I found that even with this, your notebook is slow, but this speeds up tab switching by ~30-50%. Even at a 50% speed up, this does not meet a typical users SLA.

CC @echarles

@echarles
Copy link
Contributor

@echarles echarles commented Jul 22, 2021

Hi, I made an attempt to use the idea to have a "Window" when loading a notebook in #9925. Only the visible cells in the viewport was loaded in the DOM, the cells before and after were not loaded. When the user was scrolling up and down, the cells coming into the defined viewport were loaded and the cells going out of the viewport were unloaded.

The positive effect was that the tab switching was faster, as the browser had only to load the visible portion of the notebook.

Some negative effects of this approach:

1.- When scrolling (fast), the user was seeing that the cells were going from an unrendered state to a rendered state.
2.- There was also an unsolved issue as the state of the output (e.g. in case of a react visualization) was lost.

In the linked PR, I was able to save the state of the react output, but was I wanted to display them again, the lumino widget was not showing it again (see my comment #9925 (comment)).

I am not sure if we want to continue that exploration:

  • Will we agree to have such a visible glitch for a standard (not heavy) notebook
  • I have not found a way to redisplay the react output (or other visualization).
  • I also see in the last dev meeting minutes questions on the current virtual notebook where @krassowski mentions Mike: set numberCellsToRenderDirectly to Inf for 3.1 and enable with lower number in 3.2?. I guess we have to get buy-in of the current implementation which targets the notebook load (not switch) before adding more.

A side note is that CodeMirror.next is much cheaper to load, so this issue may vanish if we just move to CodeMirror.next. However, this will just mitigate the issue, but not solve the fundamental limitation of the current system where a notebook with many cells and outputs may reach anyway the typical user SLA @mlucool mentions.

@krassowski
Copy link
Member

@krassowski krassowski commented Jul 22, 2021

I guess we have to get buy-in of the current implementation which targets the notebook load (not switch) before adding more.

To clarify: I'm not against merging more work, just seeing more rough edge cases around the current implementation that I am afraid we won't be able to resolve before 3.1.

Speaking of alternative approaches, did we already try to set content-visibility and contain one entire MainAreaWidget to prevent layout re-flows? I think I saw experiments on using this on cells which was causing issues if I remember correctly, but it actually might giv emuch more benefit if applied to entire tab. What do you think?

Edit: also we might have been missing contain-intrinsic-size

@echarles
Copy link
Contributor

@echarles echarles commented Jul 22, 2021

To clarify: I'm not against merging more work, just seeing more rough edge cases around the current implementation that I am afraid we won't be able to resolve before 3.1.

Sure, any edge cases so far?

IMHO There is a trade-off with the current virtual notebook approach: the user sees the notebook while the cells are still being rendered, which makes jupyterlab less responsible on scroll during the time. Once the cells are fully rendered, there should not be any impact (the last fixes ensure also that the last cell is correctly rendered, even when the user type rapidly SHIFT-Enter)

Speaking of alternative approaches, did we already try to set content-visibility and contain one entire MainAreaWidget to prevent layout re-flows? I think I saw experiments on using this on cells which was causing issues if I remember correctly, but it actually might giv emuch more benefit if applied to entire tab. What do you think?

We have removed content-visibility as giving issues with the scrollbar

We have used css contain in #9382 on the mainarea widget. Is this what you are thinking to?

Set contain=strict to avoid many forced layout rendering while adding cells. Don't forget to remove the CSS class when your remove the spinner to allow the content to be rendered.

Edit: also we might have been missing contain-intrinsic-size

We have not tried that property. Worth trying. As said above, even if it helps with the current CodeMirror, CodeMirror.next generate less forced layout due to editor height change. This can help the current situation, waiting on CodeMirror.next, but at some point will have limits, especially with many visual outputs.

@fcollonval
Copy link
Member

@fcollonval fcollonval commented Jul 27, 2021

Hey

I can help on this. From what I read of the various benchmarks, a major bottleneck is the layout computation of all CodeMirror instance. So as suggested by @echarles, I see three paths (not exclusive):

  1. Upgrading to Codemirror.next
  2. Using only one Codemirror instance per notebook
  3. Virtual notebook

Is there some other solutions? Which one should be tried first - I tend to think about upgrading to codemirror.next as it is needed for v4 (and the earlier the better for that) ?

@mlucool
Copy link
Contributor

@mlucool mlucool commented Jul 27, 2021

We hope to release a blog post on some of the history/things tried in this area in the near future.

Maybe it would be good to setup a community meeting on this topic?

@meeseeksmachine
Copy link
Contributor

@meeseeksmachine meeseeksmachine commented Jul 27, 2021

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/performance-analysis-and-improvements/10126/1

@fcollonval
Copy link
Member

@fcollonval fcollonval commented Jul 27, 2021

Maybe it would be good to setup a community meeting on this topic?

Sounds like a great idea. I opened a discussion on the forum (link in above bot comment) to iterate on a good time for that meeting.

cc @echarles @goanpeca

@echarles
Copy link
Contributor

@echarles echarles commented Jul 28, 2021

A side note is that CodeMirror.next is much cheaper to load, so this issue may vanish if we just move to CodeMirror.next. However, this will just mitigate the issue, but not solve the fundamental limitation of the current system where a notebook with many cells and outputs may reach anyway the typical user SLA @mlucool mentions.

Thinking more, I am not sure moving to CodeMirror.next will have an effect on tab switch (it will for sure on tab load). We have not yet profiled the tab switch like we had done for the tab load (https://jupyterlab-benchmarks.readthedocs.io/en/latest/measures/profiling.html), but my guess (to be confirmed) is that the browser just takes time to make visible again all the DOM nodes that were made hidden via CSS.

@krassowski
Copy link
Member

@krassowski krassowski commented Jul 28, 2021

I agree more profiling is needed. A very quick profiling on 3.1 with Chrome - refresh() of CodeMirror is still a major bottleneck when switching tabs:

Screenshot from 2021-07-28 15-01-02

My first instinct is that we should not be reinventing the wheel, and don't need to write new code but instead fix the existing issue:

  1. we should not be calling _editor.refresh() when switching between notebooks if notebook is fully rendered and no resize happened since it was last shown
  2. we should not be calling _editor.refresh() at every resize, we should have a debouncer or another rate limitter (so that resizing works smoothly)
  3. (possibly, not sure of this one) we should avoid calling _editor.refresh() synchronously and instead schedule it with window.setTimeout

I made a draft PR #10718 demonstrating a proof-of-concept for the above if you want to check it out on binder, but it is a bit naive (this is not actually checking the render state/resize history so it has a downside of showing editors which are not ready yet). I will not be working on it more this week, so please feel free to pick it up and perform your own experiments.

@echarles
Copy link
Contributor

@echarles echarles commented Jul 28, 2021

I have gone the refresh road with eg. #9384 but got paused with #9384 (comment), quoting @ellisonbg I am very nervous about this. Over the years we have found a range of unexepected situations where we needed to call refresh. A lot of these were related to situations that cause CodeMirror to need to recompute its dimensions and adjust its layout. This includes:...

What you bring with you WIP PR may have less potential side-effect, as you are debouncing, and not disabling on update-request.

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Jul 28, 2021

@mlucool
Copy link
Contributor

@mlucool mlucool commented Aug 3, 2021

I'd encourage anyone who plans to attend tomorrow to read through https://jupyterlab-benchmarks.readthedocs.io/en/latest/. It has a lot of brainstorming ideas.

@echarles Did we ever resolve jupyterlab/benchmarks#49? If not, I think that thread may be helpful for people to read up on to understand the lumino/jlab/codemirror interaction.

@mlucool
Copy link
Contributor

@mlucool mlucool commented Aug 3, 2021

Also while much has been implemented from #9279, @echarles's slide deck shows some of what is done and some of what we have thought about but did not do: https://jupyterlab-benchmarks-root-causes.echarles.vercel.app/

@echarles
Copy link
Contributor

@echarles echarles commented Aug 4, 2021

@echarles Did we ever resolve jupyterlab/benchmarks#49? If not, I think that thread may be helpful for people to read up on to understand the lumino/jlab/codemirror interaction.

jupyterlab/benchmarks#49 is about finding the root causes of the performance issues. A first step is to split the place where issues occur as document on https://jupyterlab-benchmarks.readthedocs.io/en/latest/issues/types.html

Browser <--> Client JS <------> API Server Endpoint <-> Content Service <-> Notebook
  [A]           [B]       [C]                                 [D]

- [A] Browser Rendering
- [B] Client-side Notebook Parsing, Validation and Preparation
- [C] Server to Client Notebook Transmission over the Network
- [D] Server-side Notebook Read, Parsing, Validation, Trust

The less obvious one to explain is at the Browser side, for which the profiling https://jupyterlab-benchmarks.readthedocs.io/en/latest/measures/profiling.html and the fix strategies https://jupyterlab-benchmarks.readthedocs.io/en/latest/fixes/strategies.html try to address the definition and the fix of the bootlenecks at the browser side.

The linked deck https://jupyterlab-benchmarks-root-causes-echarles.vercel.app is from Nov 2020 and may need a refresh based what we have discussed and done so far, but is also a good place to start.

@echarles
Copy link
Contributor

@echarles echarles commented Aug 4, 2021

I agree more profiling is needed. A very quick profiling on 3.1 with Chrome - refresh() of CodeMirror is still a major bottleneck when switching tabs:

Another profile snapshot (taken at the start of a tab switch and stopped when the tab become usable) that shows (looks at the % column) that most of the time is spent in codemirror.js

Screenshot 2021-08-04 at 18 37 29

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Aug 4, 2021

@echarles There is a simple test we can do to better understand this. On the classic notebook (which also uses codemirror) is there a similar number of calls to the codemirror API as JupyterLab?

@echarles
Copy link
Contributor

@echarles echarles commented Aug 10, 2021

Did a few more analysis. During the tab switching, I was expecting to see a lot of codemirror refresh invocation, but finally only saw 2 of them, related to the focus event. I then manually changed the CSS of the notebook panel to see how much time it was taking to hide / unhide it self. I have the impression that time taken during that manual change corresponds to the time taken when I change tab, which would make think that the browser just needs time to hide/unhide. I also tried various option to hide elements as summarised in https://www.sitepoint.com/hide-elements-in-css but none of them gave any sensible improvement.

@williamstein
Copy link

@williamstein williamstein commented Aug 10, 2021

I also did some more tests last night which are consistent with what
@echarles observed above:

  • I tried comparing the time to switch to a notebook tab in both
    CoCalc and JupyterLab, and it was about the same. Both are just using
    the approach of CSS to show/hide.
  • I tried CoCalc's "Jupyter classic in an iframe", which also uses CSS
    to show/hide, and it was just as slow. This suggests the approach of
    just using an iframe doesn't actually help. Obviously it would be
    good for somebody else to try something similar in JupyterLab, since I
    only tried this in CoCalc where it's already implemented.

I forgot to mention I took an entirely different approach to "Sage
Worksheets" in CoCalc, which is to use a single CodeMirror editor
for the entire document. The between parts with Markdown (or HTML in
Sage worksheets) are rendered using CodeMirror line widgets.
CodeMirror itself then takes care of all windowing and virtualization.
This does scale up very well in terms of performance and switching,
but of course has its own challenges. It's still very interesting,
because I think something like this could make sense as an alternative
frontend for Jupyter notebooks -- it's different since the entire
notebook is a single document, e.g., you can easily copy/past from the
middle of one cell to the middle of another cell, or create multiple
cursors anywhere, and find/replace is pretty sensible (though
restricted to the input). I have not implemented such a frontend for
cocalc-Jupyter yet, though I have always wanted to. Basically,
the idea is to let CodeMirror deal with all the windowing problems,
and to use only a single CodeMirror editor. I wrote this for "Sage
Worksheets" probably 7 years ago, and a lot of people have used it
over the years and liked it, so there's that in its favor. Is also
nice because you can select emacs, vim, sublime or regular keybindings
and those let you fully navigate your document from the keyboard in a
way that is more familiar to new users than having different modes
like with Jupyter.

My other "radical" idea is to build a Jupyter WYSIWYG editor on top of
Slate or Prosemirror that also has windowing/virtualization. I'm not
aware of any virtualization support for Prosemirror (it could just be
my ignorance), but I wrote some for Slate and do intend to push
through such an option for cocalc-Jupyter at some point this year, at
least to see what it is like.

In any case, I personally have cared a lot about supporting being able
to scale up to really long documents, even if CoCalc isn't
particularly good at it now. I've at least spent a lot of time on
this problem, and plan to spend more, and I'm very interested in this
topic.

@echarles
Copy link
Contributor

@echarles echarles commented Aug 10, 2021

My other "radical" idea is to build a Jupyter WYSIWYG editor on top of Slate or Prosemirror that also has windowing/virtualization. I'm not aware of any virtualization support for Prosemirror (it could just be my ignorance), but I wrote some for Slate and do intend to push through such an option for cocalc-Jupyter at some point this year, at least to see what it is like.

Are you considering something like RStudio which has a single editor hosting the cells? I have implemented something similar a few years ago with CodeMirror and have recently been looking at it with the Monaco and CodeMirror.next APIs. But if the number of DOM nodes to hide/display is confirmed to be the bottleneck, some windowing/virtualization system will be anyway needed. @williamstein any link to the current support you mentioned for windowing/virtualization by Slate/Prosemirror?

@williamstein
Copy link

@williamstein williamstein commented Aug 10, 2021

Are you considering something like RStudio which has a single editor hosting the cells?

I think that's almost exactly what I meant by "Sage Worksheets" in CoCalc. CodeMirror automatically does configurable windowing/virtualization. To play with this in CoCalc, in a project:

  1. Click +New
  2. Click "Sage Worksheet"
  3. Type some python and hit shift+enter.

@williamstein any link to the current support you mentioned for windowing/virtualization by Slate/Prosemirror?

This is the core of the Slate windowing implementation: https://github.com/sagemathinc/cocalc/blob/master/src/packages/frontend/editors/slate/slate-react/components/children.tsx

It's live in CoCalc if you:

  1. Create or open a Markdown file (ending in .md),
  2. Click the button on the right labeled "Locked" to switch it to say "Editable".

You can sort of see what it would feel like for Jupyter by just using nbconvert to convert an ipynb to markdown, then open it as above.

That said, web-based collaborative WYSIWYG editing of Markdown, where some users are using a WYSIWYG editor and other users may be directly editing the underlying md file, is -- in my experience -- difficult. That said, it's nice to use when it works :-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.