When using stepwise to run a protocol that itself runs stepwise (a usage model I very much want to support), I currently run into the problem that the child stepwise will notice that it's not connected to a TTY and output its protocol as a pickle. This breaks load() as it is written now (and not with a good error message), but there are two ways to fix it:
Run the subprocess with a pseudo-TTY, to trick the child stepwise comand into printing its protocol to stdout. My tests already work like this, but based on my experience with those tests, I suspect that this will impose an unacceptable performance penalty.
When parsing the content, also try parsing it as a pickle. This is nice because it avoids having to parse the protocol again, which is the whole point of the pickle. In a way, it's actually kinda elegant. The problem is that this starts to blur the line between load() and ProtocolIO in a way that I need to think more about.
In the meantime, nested protocols can work around this issue by calling stepwise with the -x flag. This will continue to work even after this bug is fixed, which is nice.
kalekundert
commented
4 years ago
When using stepwise to run a protocol that itself runs stepwise (a usage model I very much want to support), I currently run into the problem that the child stepwise will notice that it's not connected to a TTY and output its protocol as a pickle. This breaks
load()as it is written now (and not with a good error message), but there are two ways to fix it:Run the subprocess with a pseudo-TTY, to trick the child stepwise comand into printing its protocol to stdout. My tests already work like this, but based on my experience with those tests, I suspect that this will impose an unacceptable performance penalty.
When parsing the content, also try parsing it as a pickle. This is nice because it avoids having to parse the protocol again, which is the whole point of the pickle. In a way, it's actually kinda elegant. The problem is that this starts to blur the line between
load()andProtocolIOin a way that I need to think more about.In the meantime, nested protocols can work around this issue by calling
stepwisewith the-xflag. This will continue to work even after this bug is fixed, which is nice.