Show progress on preview & improve execution end detection

[Splines]

Closes #14.

This is a further step towards a terminal-free workflow. Here we add add notifications that show the current progress of the executed Manim command, e.g. which part of the scene is executing and with which percentage. Furthermore, we show an infinite progress when a new Manim session is started.

Feature preview

manim.with.progress.notification.mp4

In the preview, note how the shell is automatically opened if any command has to send a keyboard interrupt. This is because VSCode itself opens the terminal in this case. This is a known limitation and won't be fixed in this PR.

Further off-topic changes

• When the user opens a new terminal and executes manimgl manually in there, we close a Manim session that is open in another terminal. This is to avoid multiple open Manim sessions at the same time.
• ⚠ The detection of the end of a command execution (like code preview) was made more robust by also taking the IPython cell count into consideration to avoid false positives. See for example this comment.
• On Linux, it is currently possible to interrupt a running command. When doing so, a Ctrl+C is sent. Starting with this PR, we manually send the Ctrl+C instead to know exactly when this happens and to therefore render our control flow more easy. This also has the advantage that we could add other commands to send there, e.g. when we find an alternative on MacOS since Ctrl+C in Interactive Manim is apparently not working there, see [bug] Quits if "Preview Manim Cell" before it finishes #16.

[bhoov]

Feature is really nice, but I'm getting a bug on my MacOS system where the changes in this PR break my ability to run a cell. Somehow, the extension always thinks that an existing command is already running. See video below.

ScreenRecording.mov

The current main branch does not have this bug

[Splines]

@bhoov Could you test it again now? If the error persists, could you replace these lines by the following and see if it works?

this.eventEmitter.once(ManimShellEvent.IPYTHON_CELL_FINISHED, resolve);

[bhoov]

If I replace the specified lines with your suggestion, it works as normal. Is this the recommended fix?

Edit: that is, if I only rebase with main the issue persists. I had to modify your specified lines to your suggestion to get expected behavior

[Splines]

If I replace the specified lines with your suggestion, it works as normal. Is this the recommended fix?

No, it just tells me that we experience different behaviors. For me, when issuing the command, I receive the command just sent in the data stream. Therefore, I have to skip the first In [42]: before matching the actual "end" (next start of the IPython cell). Otherwise, I issue the command, get back the command itself as string and will think that the command is not executing anymore.

In the terminal, do you notice that sometimes empty In [...]: blocks are executed? E.g. two In [8] in a row? (where the 8 is not incremented).

[bhoov]

No, i have not noticed this at all, though I have only just now run a few tests.

I wonder if this is a bug that accompanies the nice feature WSL supports to interrupt a currently running cell?

[Splines]

Could you add the following before this line:

console.log(`🎯: ${data}`);

Then do some experiments and send me the log?

[bhoov]

Not sure what you are looking for. Here is what is shown in the debug console on my machine for a few random cells in the example_scenes.py

debug-macos.log

[Splines]

As an example: when I manually type ls in the terminal, then press enter, I see this output:

Here you see why I skip the first In [12]. Maybe to make this more robust I could store the number of the cell where we execute the command in, and then wait for the counter + 1 cell to arrive.

And thanks for the log 👍

[bhoov]

I will revisit this bug when I get back home. Thx @Splines!

[Splines]

Ok, could you also add the following before this line:

console.log(`🌟: ${command}`);

and then send me the log again? Since your previous log seems pretty normal. I have to find out when the command is issued and when you get this info in the datastream. If this is similar for us both, there's probably another reason why this is not working for you. Here is my log:

wsl-preview.log

As you can see:

I retrieve the command that I just executed directly in the data stream, which is why I want to skip the first In [...] line I'm encountering. Is this order different for you?

[Splines]

In the last commits, I've made the detection of the end of a cell execution more robust. Please try it out again on MacOS. I've also added missing docstrings and explained off-topic changes in the PR comment.

I've left some console log statements to ease debugging (sending logfiles) in case if it still does not work on MacOS. In contrary, if it works and you approve, please remove all five console.log statements.

Upon merging please remove all commits prior to 6cad6ec (Prevent multiple commands from running on MacOS) from the squash-commit message. After that, some commits are still from other branches, but it's probably useless and too much effort to filter them out.

[bhoov]

Yer a wizard @Splines

[bhoov]

Omg, everything works as expected and the whole extension is starting to feel very polished on my end <3