Hydrogen: Break/interrupt kernel and continue using envirnoment; Bug?

[tobiasbj]

Hi,
as far as I understand it is not possible to currently interrupt/break some running code and continue using the up until the then computed variables. Atleast if I use the 'interrupt-kernel' command I am unable to run new code before restarting the kernel (this could be a local issue, but I have also seen the same issue among friends). Meaning I have to run all the code again (which is kind of tedious when testing). Is this meant to work or is it not currently implemented?

Note: I have tried searching for similar issues without success. It could however be that I have used the wrong wording. If that is the case, my apologies.

Best,
Tobias

[lgeiger]

Hi Tobias,

thanks for opening the issue!
Interrupting a running kernel should definitely not require a kernel restart.

Take a look at the following example in python:

Could you provide more information about which kernel and which version of Atom and Hydrogen you are running?

[tobiasbj]

Hi thanks for the fast response,

My system info:
OS: Windows 10
Hydrogen 1.5.1
Atom 1.13.0
Kernel: Python 3 (3.5.2 using Anaconda 4.2.0)

Uncertain how to show an example like you did above, but if I do the exact same thing I do not get the usual "Keyboard interrupt" (ctrl-c) message. I simply get the "inprogress symbol" permanently active until I restart the kernel.

[lgeiger]

Oh no this looks like a Windows specific issue.

@rgbkrk @n-riesco Could it be that Windows doesn't support the SIGINT signal we use to interrupt the kernel process?

@tobiasbj Could you post the output of the developer tools as described in our Debugging Guide after you tried to interrupt the kernel?

[lgeiger]

I had a look at the Node.js docs:

Note: Windows does not support sending signals, but Node.js offers some emulation with process.kill(), and ChildProcess.kill(). Sending signal 0 can be used to test for the existence of a process. Sending SIGINT, SIGTERM, and SIGKILL cause the unconditional termination of the target process.

So on windows instead of interrupting the kernel it's killed.
I'm not aware of any workarounds so we probably should disable interrupting on windows since it doesn't do the right thing.

@tobiasbj You can try and use remote kernels which should handle interrupt messages on windows as well.