forum.polymake.org

Well, maybe the function name sounds misleading. simulate_shell_input does exactly what you want, just avoiding any fuss with pseudo-terminals, because perl can process any strings as long as they fit into the memory. Thus if you start polymake using the callable library object polymake::Main, it does not look for any ttys but waits for commands supplied via simulate_shell_input (and other functions provided by the callable library, of course). The advantage over scripts is, first, less overhead - no need to create temp files and wipe them away later, second, no stored precompiled script bodies, and third, homogeneous syntax rules: the input provided by this function is treated more rigorously, without automatic declaration. If you want polymake to keep track of the variables, then all you need is to issue a 'declare $SAGE27;' when the variable comes into existence on the Sage side, then you can assign anything you want to it as long as the session lasts, or undef it if you want to save memory but keep the variable declared. You can even introduce one large array of variables, like @SAGEVAR, which you declare during the start-up and then substitute $SAGEVARS[27] in all expressions.

Well, maybe the function name sounds misleading. simulate_shell_input does exactly what you want, just avoiding any fuss with pseudo-terminals, because perl can process any strings as long as they fit into the memory. Thus if you start polymake using the callable library object polymake::Main, it does not look for any ttys but waits for commands supplied via simulate_shell_input (and other functions provided by the callable library, of course).

As I said before: This is useful for a library interface (pypolymake), but doesn't apply to a pexpect interface.

Understood. At least, you should generate all your temporary scripts with the same file name, then polymake will store only one compiled script body.