Jeremy Tuloup

Hopefully some online setup like the one proposed in https://github.com/jupyterlite/jupyterlite/pull/672 can help hide that complexity. Especially when making smaller edits by occasional contributors. Probably `dodo.py` will also be cleaned up...

Seeing that one locally even when committing a single file: https://github.com/jupyterlite/jupyterlite/blob/main/packages/application-extension/src/index.tsx Could be because this one is a `.tsx`.

Seeing that one less often now with #240, although the eslint check still takes quite a bit of time on commit.

> Seeing that one less often now with #240, although the eslint check still takes quite a bit of time on commit. Still seeing it on the latest `main`.

Still seeing these errors when overall RAM usage is high: 

Reopening as this still seems to be happening, also for other folks. cc @martinRenou

One difference compared to VS code is that we always seem to have one more ~scope~ frame on line 2. Which would explain why the `next` command will add that...

As a side-effect, we can continue breaking and stepping even after removing the breakpoints: 

Which is most likely related to how the code is executed in `xeus-python`: - the `` source coming from: https://github.com/QuantStack/xeus-python/blob/507786ce6e726ba3ea518f99fce5636e2e46d329/src/xinterpreter.cpp#L126 - the execution: https://github.com/QuantStack/xeus-python/blob/507786ce6e726ba3ea518f99fce5636e2e46d329/src/xinterpreter.cpp#L150-L156 

> I wonder if this behavior does not come from the way we initialize ptvsd That is also one possibility yes.