Is there any way to stop pyStata while running?

[John Williamss]

We know that both python and Stata have the stop-process capability, but it seems impossible to do that through pystata. For example, suppose we run the following code:

import stata_setup
stata_setup.config("C:/Program Files/Stata17", "mp")
from pystata import stata

stata.run('''
foreach i  of numlist 1/4 {
    disp `i'
 sleep 1000
}
disp "End"
''')

And in the middle, we understand it is taking too long. Stopping the process through python does not work (I'm using Spyder IDE) and waits for the whole process to complete. Here is the video:
https://imgur.com/x92sRco

The other bug is that the rest of the python code becomes unstoppable when the stop is hit! because the stop has been hit once. For example, suppose we have the following code

import stata_setup
stata_setup.config("C:/Program Files/Stata17", "mp")
from pystata import stata
for i in range(10**3):
   stata.run('''
    sleep 1000
   ''')
print("end")

Suppose we are in loop number 100 we understand this is taking a long time, and we hit stop. It does not stop; everything gets greyed out, and even the python can't be stopped. Many other unpredictable issues sometimes occur as well when ctrl+c is hit. For example, in this video:
https://imgur.com/a/pr8BGgp

[Daniel Schaefer]

Hi John,

I'm not sure, but my guess is that you've found a bug in the interface, whereby the stop command isn't forwarded properly to the Stata process that is spawned by the run command. You might want to ask Stata support about this directly.

In my experience, writing an interface between different platforms can be one of the hardest things to do in software engineering. A big reason for this is that you have to deal with multiple concurrent processes, which can be very challenging. Some of your problems (I'm thinking of your second video) may be related to the fact that Stata might implement the sleep command using a low-level multithreading API provided by the OS.

I wonder if Tim Huegerich has any thoughts on this.

[John Williamss]

Hi John,

I'm not sure, but my guess is that you've found a bug in the interface, whereby the stop command isn't forwarded properly to the Stata process that is spawned by the run command. You might want to ask Stata support about this directly.

In my experience, writing an interface between different platforms can be one of the hardest things to do in software engineering. A big reason for this is that you have to deal with multiple concurrent processes, which can be very challenging. Some of your problems (I'm thinking of your second video) may be related to the fact that Stata might implement the sleep command using a low-level multithreading API provided by the OS.

I wonder if Tim Huegerich has any thoughts on this.

Thanks. The sleep command serves as an expositional example to make things concrete. I don't use sleep in my actual code. Instead, you can think of generating a random dataset task or anything.

[Daniel Schaefer]

Of course. Are you saying you can reproduce both videos (which appear to behave differently) without resorting to the sleep command?

[Tim Huegerich]

I'm not sure, but my guess is that you've found a bug in the interface, whereby the stop command isn't forwarded properly to the Stata process that is spawned by the run command. You might want to ask Stata support about this directly..

This seems right to me.

I've recently pondered a likely-related issue when testing out what happens when `set more on` or `pause` are triggered within `pystata.stata.run` in a Jupyter notebook. I haven't found a way to send keyboard input to Stata, so my only recourse has been to restart the kernel.

[John Williamss]

Of course. Are you saying you can reproduce both videos (which appear to behave differently) without resorting to the sleep command?

For the first one, I'm pretty sure about that, as that was why I'm having problems with my code. It's just in any code. For the second one, I can check and get back to